Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: hisilicon/debugfs - Fix debugfs uninit process issue<br /> <br /> During the zip probe process, the debugfs failure does not stop<br /> the probe. When debugfs initialization fails, jumping to the<br /> error branch will also release regs, in addition to its own<br /> rollback operation.<br /> <br /> As a result, it may be released repeatedly during the regs<br /> uninit process. Therefore, the null check needs to be added to<br /> the regs uninit process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnx2x: Fix multiple UBSAN array-index-out-of-bounds<br /> <br /> Fix UBSAN warnings that occur when using a system with 32 physical<br /> cpu cores or more, or when the user defines a number of Ethernet<br /> queues greater than or equal to FP_SB_MAX_E1x using the num_queues<br /> module parameter.<br /> <br /> Currently there is a read/write out of bounds that occurs on the array<br /> "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"<br /> struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".<br /> Looking at the definition of the "struct stats_query_entry query" array:<br /> <br /> struct stats_query_entry query[FP_SB_MAX_E1x+<br /> BNX2X_FIRST_QUEUE_QUERY_IDX];<br /> <br /> FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and<br /> has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3<br /> meaning the array has a total size of 19.<br /> Since accesses to "struct stats_query_entry query" are offset-ted by<br /> BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet<br /> queues should not exceed FP_SB_MAX_E1x (16). However one of these queues<br /> is reserved for FCOE and thus the number of Ethernet queues should be set<br /> to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if<br /> it is not.<br /> <br /> This is also described in a comment in the source code in<br /> drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition<br /> of FP_SB_MAX_E1x. Below is the part of this explanation that it important<br /> for this patch<br /> <br /> /*<br /> * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is<br /> * control by the number of fast-path status blocks supported by the<br /> * device (HW/FW). Each fast-path status block (FP-SB) aka non-default<br /> * status block represents an independent interrupts context that can<br /> * serve a regular L2 networking queue. However special L2 queues such<br /> * as the FCoE queue do not require a FP-SB and other components like<br /> * the CNIC may consume FP-SB reducing the number of possible L2 queues<br /> *<br /> * If the maximum number of FP-SB available is X then:<br /> * a. If CNIC is supported it consumes 1 FP-SB thus the max number of<br /> * regular L2 queues is Y=X-1<br /> * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)<br /> * c. If the FCoE L2 queue is supported the actual number of L2 queues<br /> * is Y+1<br /> * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for<br /> * slow-path interrupts) or Y+2 if CNIC is supported (one additional<br /> * FP interrupt context for the CNIC).<br /> * e. The number of HW context (CID count) is always X or X+1 if FCoE<br /> * L2 queue is supported. The cid for the FCoE L2 queue is always X.<br /> */<br /> <br /> However this driver also supports NICs that use the E2 controller which can<br /> handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.<br /> Looking at the commits when the E2 support was added, it was originally<br /> using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").<br /> Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver<br /> was later updated to take full advantage of the E2 instead of having it be<br /> limited to the capabilities of the E1x. But as far as we can tell, the<br /> array "stats_query_entry query" was still limited to using the FP-SB<br /> available to the E1x cards as part of an oversignt when the driver was<br /> updated to take full advantage of the E2, and now with the driver being<br /> aware of the greater queue size supported by E2 NICs, it causes the UBSAN<br /> warnings seen in the stack traces below.<br /> <br /> This patch increases the size of the "stats_query_entry query" array by<br /> replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle<br /> both types of NICs.<br /> <br /> Stack traces:<br /> <br /> UBSAN: array-index-out-of-bounds in<br /> drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11<br /> index 20 is out of range for type &amp;#39;stats_query_entry [19]&amp;#39;<br /> CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic<br /> #202405052133<br /> Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix a possible leak when destroy a ctrl during qp establishment<br /> <br /> In nvmet_sq_destroy we capture sq-&gt;ctrl early and if it is non-NULL we<br /> know that a ctrl was allocated (in the admin connect request handler)<br /> and we need to release pending AERs, clear ctrl-&gt;sqs and sq-&gt;ctrl<br /> (for nvme-loop primarily), and drop the final reference on the ctrl.<br /> <br /> However, a small window is possible where nvmet_sq_destroy starts (as<br /> a result of the client giving up and disconnecting) concurrently with<br /> the nvme admin connect cmd (which may be in an early stage). But *before*<br /> kill_and_confirm of sq-&gt;ref (i.e. the admin connect managed to get an sq<br /> live reference). In this case, sq-&gt;ctrl was allocated however after it was<br /> captured in a local variable in nvmet_sq_destroy.<br /> This prevented the final reference drop on the ctrl.<br /> <br /> Solve this by re-capturing the sq-&gt;ctrl after all inflight request has<br /> completed, where for sure sq-&gt;ctrl reference is final, and move forward<br /> based on that.<br /> <br /> This issue was observed in an environment with many hosts connecting<br /> multiple ctrls simoutanuosly, creating a delay in allocating a ctrl<br /> leading up to this race window.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr<br /> <br /> When del_timer_sync() is called in an interrupt context it throws a warning<br /> because of potential deadlock. The timer is used only to exit from<br /> wait_for_completion() after a timeout so replacing the call with<br /> wait_for_completion_timeout() allows to remove the problematic timer and<br /> its related functions altogether.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp_metrics: validate source addr length<br /> <br /> I don&amp;#39;t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4<br /> is at least 4 bytes long, and the policy doesn&amp;#39;t have an entry<br /> for this attribute at all (neither does it for IPv6 but v6 is<br /> manually validated).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bluetooth/hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX<br /> <br /> Syzbot hit warning in hci_conn_del() caused by freeing handle that was<br /> not allocated using ida allocator.<br /> <br /> This is caused by handle bigger than HCI_CONN_HANDLE_MAX passed by<br /> hci_le_big_sync_established_evt(), which makes code think it&amp;#39;s unset<br /> connection.<br /> <br /> Add same check for handle upper bound as in hci_conn_set_handle() to<br /> prevent warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Ignore too large handle values in BIG<br /> <br /> hci_le_big_sync_established_evt is necessary to filter out cases where the<br /> handle value is belonging to ida id range, otherwise ida will be erroneously<br /> released in hci_conn_cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-pci: Check if is_avq is NULL<br /> <br /> [bug]<br /> In the virtio_pci_common.c function vp_del_vqs, vp_dev-&gt;is_avq is involved<br /> to determine whether it is admin virtqueue, but this function vp_dev-&gt;is_avq<br /> may be empty. For installations, virtio_pci_legacy does not assign a value<br /> to vp_dev-&gt;is_avq.<br /> <br /> [fix]<br /> Check whether it is vp_dev-&gt;is_avq before use.<br /> <br /> [test]<br /> Test with virsh Attach device<br /> Before this patch, the following command would crash the guest system<br /> <br /> After applying the patch, everything seems to be working fine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost_task: Handle SIGKILL by flushing work and exiting<br /> <br /> Instead of lingering until the device is closed, this has us handle<br /> SIGKILL by:<br /> <br /> 1. marking the worker as killed so we no longer try to use it with<br /> new virtqueues and new flush operations.<br /> 2. setting the virtqueue to worker mapping so no new works are queued.<br /> 3. running all the exiting works.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix improper extts handling<br /> <br /> Extts events are disabled and enabled by the application ts2phc.<br /> However, in case where the driver is removed when the application is<br /> running, a specific extts event remains enabled and can cause a kernel<br /> crash.<br /> As a side effect, when the driver is reloaded and application is started<br /> again, remaining extts event for the channel from a previous run will<br /> keep firing and the message "extts on unexpected channel" might be<br /> printed to the user.<br /> <br /> To avoid that, extts events shall be disabled when PTP is released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: ISO: Check socket flag instead of hcon<br /> <br /> This fixes the following Smatch static checker warning:<br /> <br /> net/bluetooth/iso.c:1364 iso_sock_recvmsg()<br /> error: we previously assumed &amp;#39;pi-&gt;conn-&gt;hcon&amp;#39; could be null (line 1359)<br /> <br /> net/bluetooth/iso.c<br /> 1347 static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg,<br /> 1348 size_t len, int flags)<br /> 1349 {<br /> 1350 struct sock *sk = sock-&gt;sk;<br /> 1351 struct iso_pinfo *pi = iso_pi(sk);<br /> 1352<br /> 1353 BT_DBG("sk %p", sk);<br /> 1354<br /> 1355 if (test_and_clear_bit(BT_SK_DEFER_SETUP,<br /> &amp;bt_sk(sk)-&gt;flags)) {<br /> 1356 lock_sock(sk);<br /> 1357 switch (sk-&gt;sk_state) {<br /> 1358 case BT_CONNECT2:<br /> 1359 if (pi-&gt;conn-&gt;hcon &amp;&amp;<br /> ^^^^^^^^^^^^^^ If -&gt;hcon is NULL<br /> <br /> 1360 test_bit(HCI_CONN_PA_SYNC,<br /> &amp;pi-&gt;conn-&gt;hcon-&gt;flags)) {<br /> 1361 iso_conn_big_sync(sk);<br /> 1362 sk-&gt;sk_state = BT_LISTEN;<br /> 1363 } else {<br /> --&gt; 1364 iso_conn_defer_accept(pi-&gt;conn-&gt;hcon);<br /> ^^^^^^^^^^^^^^<br /> then we&amp;#39;re toast<br /> <br /> 1365 sk-&gt;sk_state = BT_CONFIG;<br /> 1366 }<br /> 1367 release_sock(sk);<br /> 1368 return 0;<br /> 1369 case BT_CONNECTED:<br /> 1370 if (test_bit(BT_SK_PA_SYNC,

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.