The remote Fedora 38 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2024-71f0f16533 advisory.

  - Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
    (CVE-2023-52437)

  - In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work     scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit     as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling     complete(). This seems more logical in the first place, as it's the inverse order of what the submitting     thread will do. (CVE-2024-26585)

  - In the Linux kernel, the following vulnerability has been resolved: net: tls: fix use-after-free with     partial reads and async decrypt tls_decrypt_sg doesn't take a reference on the pages from clear_skb, so     the put_page() in tls_decrypt_done releases them, and we trigger a use-after-free in process_rx_list when     we try to read from the partially-read skb. (CVE-2024-26582)

  - In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto     requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API,     crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example,     when the cryptd queue for AESNI is full (easy to trigger with an artificially low     cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case,     the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just     ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new     tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the     error handling paths. The handling is identical. (CVE-2024-26584)

  - In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and     socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto     handler calls complete() so any code past that point risks touching already freed data. Try to avoid the     locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend     solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we     are now tightly controlling when completion fires. (CVE-2024-26583)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Fix block process call     transactions According to the Intel datasheets, software must reset the block buffer index twice for block     process call transactions: once before writing the outgoing data to the buffer, and once again before     reading the incoming data from the buffer. The driver is currently missing the second reset, causing the     wrong portion of the block buffer to be read. (CVE-2024-26593)

  - In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Stop relying on userspace for     info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken     from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a     sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in     fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer     required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area     which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the     still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead,     fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak     subject / changelog ] (CVE-2024-26603)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

Detections

Analytics

Fedora 38 : kernel (2024-71f0f16533)

high Nessus Plugin ID 191083

Version 1.1

Version 1.0

Version 1.0

Version 1.1 Mar 18, 2024, 3:10 PM CVSS metrics ("CVSSv2 score" set to 6.8. "CVSSv2 vector" set to "CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C") CVSSv2 score source (changed from "CVE-2024-26593" to "CVE-2024-26582") CVSSv3 score source (changed from "CVE-2024-26603" to none) Plugin Feed: 202403181510
Version 1.0 Feb 28, 2024, 6:56 AM New Plugin Feed: 202402280656
Version 1.0 Mar 18, 2024, 1:04 PM CVSS metrics ("CVSSv2 score" set to 6.8) CVSS metrics ("CVSSv2 vector" set to "CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C") CVSSv2 score source (changed from "CVE-2024-26593" to "CVE-2024-26582") CVSSv3 score source (changed from "CVE-2024-26603" to none) Plugin Feed: 202403181304