CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42152 – nvmet: fix a possible leak when destroy a ctrl during qp establishment
https://notcve.org/view.php?id=CVE-2024-42152
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a possible leak when destroy a ctrl during qp establishment In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl. However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But *before* kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl. Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that. This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window. • https://git.kernel.org/stable/c/2f3c22b1d3d7e86712253244797a651998c141fa https://git.kernel.org/stable/c/b4fed1443a6571d49c6ffe7d97af3bbe5ee6dff5 https://git.kernel.org/stable/c/940a71f08ef153ef807f751310b0648d1fa5d0da https://git.kernel.org/stable/c/5502c1f1d0d7472706cc1f201aecf1c935d302d1 https://git.kernel.org/stable/c/818004f2a380420c19872171be716174d4985e33 https://git.kernel.org/stable/c/c758b77d4a0a0ed3a1292b3fd7a2aeccd1a169a4 https://access.redhat.com/security/cve/CVE-2024-42152 https://bugzilla.redhat.com/show_bug.cgi?id=2301519 • CWE-404: Improper Resource Shutdown or Release •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42151 – bpf: mark bpf_dummy_struct_ops.test_1 parameter as nullable
https://notcve.org/view.php?id=CVE-2024-42151
In the Linux kernel, the following vulnerability has been resolved: bpf: mark bpf_dummy_struct_ops.test_1 parameter as nullable Test case dummy_st_ops/dummy_init_ret_value passes NULL as the first parameter of the test_1() function. Mark this parameter as nullable to make verifier aware of such possibility. Otherwise, NULL check in the test_1() code: SEC("struct_ops/test_1") int BPF_PROG(test_1, struct bpf_dummy_ops_state *state) { if (!state) return ...; ... access state ... } Might be removed by verifier, thus triggering NULL pointer dereference under certain conditions. • https://git.kernel.org/stable/c/7f79097b0de97a486b137b750d7dd7b20b519d23 https://git.kernel.org/stable/c/1479eaff1f16983d8fda7c5a08a586c21891087d •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42150 – net: txgbe: remove separate irq request for MSI and INTx
https://notcve.org/view.php?id=CVE-2024-42150
In the Linux kernel, the following vulnerability has been resolved: net: txgbe: remove separate irq request for MSI and INTx When using MSI or INTx interrupts, request_irq() for pdev->irq will conflict with request_threaded_irq() for txgbe->misc.irq, to cause system crash. So remove txgbe_request_irq() for MSI/INTx case, and rename txgbe_request_msix_irqs() since it only request for queue irqs. Add wx->misc_irq_domain to determine whether the driver creates an IRQ domain and threaded request the IRQs. • https://git.kernel.org/stable/c/aefd013624a10f39b0bfaee8432a235128705380 https://git.kernel.org/stable/c/ffe8a87463c8bb885c42ed54540d06ed041e76dc https://git.kernel.org/stable/c/850103ebe6b062ee0ab0f6670205f861acc76ace https://git.kernel.org/stable/c/bd07a98178462e7a02ed2bf7dec90a00944c1da5 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42149 – fs: don't misleadingly warn during thaw operations
https://notcve.org/view.php?id=CVE-2024-42149
In the Linux kernel, the following vulnerability has been resolved: fs: don't misleadingly warn during thaw operations The block device may have been frozen before it was claimed by a filesystem. Concurrently another process might try to mount that frozen block device and has temporarily claimed the block device for that purpose causing a concurrent fs_bdev_thaw() to end up here. The mounter is already about to abort mounting because they still saw an elevanted bdev->bd_fsfreeze_count so get_bdev_super() will return NULL in that case. For example, P1 calls dm_suspend() which calls into bdev_freeze() before the block device has been claimed by the filesystem. This brings bdev->bd_fsfreeze_count to 1 and no call into fs_bdev_freeze() is required. Now P2 tries to mount that frozen block device. It claims it and checks bdev->bd_fsfreeze_count. • https://git.kernel.org/stable/c/49ef8832fb1a9e0da0020eb17480fd286433bc13 https://git.kernel.org/stable/c/25b1e3906e050d452427bc51620bb7f0a591373a https://git.kernel.org/stable/c/2ae4db5647d807efb6a87c09efaa6d1db9c905d7 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42148 – bnx2x: Fix multiple UBSAN array-index-out-of-bounds
https://notcve.org/view.php?id=CVE-2024-42148
In the Linux kernel, the following vulnerability has been resolved: bnx2x: Fix multiple UBSAN array-index-out-of-bounds Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FP_SB_MAX_E1x using the num_queues module parameter. Currently there is a read/write out of bounds that occurs on the array "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct stats_query_entry query" array: struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX]; FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct stats_query_entry query" are offset-ted by BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet queues should not exceed FP_SB_MAX_E1x (16). However one of these queues is reserved for FCOE and thus the number of Ethernet queues should be set to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if it is not. This is also described in a comment in the source code in drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition of FP_SB_MAX_E1x. Below is the part of this explanation that it important for this patch /* * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. • https://git.kernel.org/stable/c/50f0a562f8cc9ed9d9f7f7380434c3c8646172d5 https://git.kernel.org/stable/c/cfb04472ce33bee2579caf4dc9f4242522f6e26e https://git.kernel.org/stable/c/cbe53087026ad929cd3950508397e8892a6a2a0f https://git.kernel.org/stable/c/8b17cec33892a66bbd71f8d9a70a45e2072ae84f https://git.kernel.org/stable/c/0edae06b4c227bcfaf3ce21208d49191e1009d3b https://git.kernel.org/stable/c/9504a1550686f53b0bab4cab31d435383b1ee2ce https://git.kernel.org/stable/c/f1313ea92f82451923e28ab45a4aaa0e70e80b98 https://git.kernel.org/stable/c/b9ea38e767459111a511ed4fb74abc37d •