Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/xive: fix kmemleak caused by incorrect chip_data lookup<br /> <br /> The kmemleak reports the following memory leak:<br /> <br /> Unreferenced object 0xc0000002a7fbc640 (size 64):<br /> comm "kworker/8:1", pid 540, jiffies 4294937872<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 00 00 00 00 00 00 09 04 00 04 00 00 ................<br /> 00 00 a7 81 00 00 0a c0 00 00 08 04 00 04 00 00 ................<br /> backtrace (crc 177d48f6):<br /> __kmalloc_cache_noprof+0x520/0x730<br /> xive_irq_alloc_data.constprop.0+0x40/0xe0<br /> xive_irq_domain_alloc+0xd0/0x1b0<br /> irq_domain_alloc_irqs_parent+0x44/0x6c<br /> pseries_irq_domain_alloc+0x1cc/0x354<br /> irq_domain_alloc_irqs_parent+0x44/0x6c<br /> msi_domain_alloc+0xb0/0x220<br /> irq_domain_alloc_irqs_locked+0x138/0x4d0<br /> __irq_domain_alloc_irqs+0x8c/0xfc<br /> __msi_domain_alloc_irqs+0x214/0x4d8<br /> msi_domain_alloc_irqs_all_locked+0x70/0xf8<br /> pci_msi_setup_msi_irqs+0x60/0x78<br /> __pci_enable_msix_range+0x54c/0x98c<br /> pci_alloc_irq_vectors_affinity+0x16c/0x1d4<br /> nvme_pci_enable+0xac/0x9c0 [nvme]<br /> nvme_probe+0x340/0x764 [nvme]<br /> <br /> This occurs when allocating MSI-X vectors for an NVMe device. During<br /> allocation the XIVE code creates a struct xive_irq_data and stores it<br /> in irq_data-&gt;chip_data.<br /> <br /> When the MSI-X irqdomain is later freed, xive_irq_free_data() is<br /> responsible for retrieving this structure and freeing it. However,<br /> after commit cc0cc23babc9 ("powerpc/xive: Untangle xive from child<br /> interrupt controller drivers"), xive_irq_free_data() retrieves the<br /> chip_data using irq_get_chip_data(), which looks up the data through<br /> the child domain.<br /> <br /> This is incorrect because the XIVE-specific irq data is associated with<br /> the XIVE (parent) domain. As a result the lookup fails and the allocated<br /> struct xive_irq_data is never freed, leading to the kmemleak report<br /> shown above.<br /> <br /> Fix this by retrieving the irq_data from the correct domain using<br /> irq_domain_get_irq_data() and then accessing the chip_data via<br /> irq_data_get_irq_chip_data().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: libwx: fix VF illegal register access<br /> <br /> Register WX_CFG_PORT_ST is a PF restricted register. When a VF is<br /> initialized, attempting to read this register triggers an illegal<br /> register access, which lead to a system hang.<br /> <br /> When the device is VF, the bus function ID can be obtained directly from<br /> the PCI_FUNC(pdev-&gt;devfn).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: q6apm-lpass-dai: Fix multiple graph opens<br /> <br /> As prepare can be called mulitple times, this can result in multiple<br /> graph opens for playback path.<br /> <br /> This will result in a memory leaks, fix this by adding a check before<br /> opening.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-tcp: fix race between ICReq handling and queue teardown<br /> <br /> nvmet_tcp_handle_icreq() updates queue-&gt;state after sending an<br /> Initialization Connection Response (ICResp), but it does so without<br /> serializing against target-side queue teardown.<br /> <br /> If an NVMe/TCP host sends an Initialization Connection Request<br /> (ICReq) and immediately closes the connection, target-side teardown<br /> may start in softirq context before io_work drains the already<br /> buffered ICReq. In that case, nvmet_tcp_schedule_release_queue()<br /> sets queue-&gt;state to NVMET_TCP_Q_DISCONNECTING and drops the queue<br /> reference under state_lock.<br /> <br /> If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can<br /> still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the<br /> DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and<br /> allows a later socket state change to re-enter teardown and issue a<br /> second kref_put() on an already released queue.<br /> <br /> The ICResp send failure path has the same problem. If teardown has<br /> already moved the queue to DISCONNECTING, a send error can still<br /> overwrite the state with NVMET_TCP_Q_FAILED, again reopening the<br /> window for a second teardown path to drop the queue reference.<br /> <br /> Fix this by serializing both post-send state transitions with<br /> state_lock and bailing out if teardown has already started.<br /> <br /> Use -ESHUTDOWN as an internal sentinel for that bail-out path rather<br /> than propagating it as a transport error like -ECONNRESET. Keep<br /> nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before<br /> honoring that sentinel so receive-side parsing stays quiesced until the<br /> existing release path completes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: ADD_ADDR rtx: fix potential data-race<br /> <br /> This mptcp_pm_add_timer() helper is executed as a timer callback in<br /> softirq context. To avoid any data races, the socket lock needs to be<br /> held with bh_lock_sock().<br /> <br /> If the socket is in use, retry again soon after, similar to what is done<br /> with the keepalive timer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt<br /> <br /> hci_le_create_big_complete_evt() iterates over BT_BOUND connections for<br /> a BIG handle using a while loop, accessing ev-&gt;bis_handle[i++] on each<br /> iteration. However, there is no check that i stays within ev-&gt;num_bis<br /> before the array access.<br /> <br /> When a controller sends a LE_Create_BIG_Complete event with fewer<br /> bis_handle entries than there are BT_BOUND connections for that BIG,<br /> or with num_bis=0, the loop reads beyond the valid bis_handle[] flex<br /> array into adjacent heap memory. Since the out-of-bounds values<br /> typically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle()<br /> rejects them and the connection remains in BT_BOUND state. The same<br /> connection is then found again by hci_conn_hash_lookup_big_state(),<br /> creating an infinite loop with hci_dev_lock held.<br /> <br /> Fix this by terminating the BIG if in case not all BIS could be setup<br /> properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mana: Fix mana_destroy_wq_obj() cleanup in mana_ib_create_qp_rss()<br /> <br /> Sashiko points out there are two bugs here in the error unwind flow, both<br /> related to how the WQ table is unwound.<br /> <br /> First there is a double i-- on the first failure path due to the while loop<br /> having a i--, remove it.<br /> <br /> Second if mana_ib_install_cq_cb() fails then mana_create_wq_obj() is not<br /> undone due to the above i--.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/ocrdma: Don&amp;#39;t NULL deref uctx on errors in ocrdma_copy_pd_uresp()<br /> <br /> Sashiko points out that pd-&gt;uctx isn&amp;#39;t initialized until late in the<br /> function so all these error flow references are NULL and will crash. Use<br /> the uctx that isn&amp;#39;t NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi: Check event message buffer response for bad data<br /> <br /> The event message buffer response data size got checked later when<br /> processing, but check it right after the response comes back. It<br /> appears some BMCs may return an empty message instead of an error<br /> when fetching events.<br /> <br /> There are apparently some new BMCs that make this error, so we need to<br /> compensate.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-verity-fec: fix reading parity bytes split across blocks (take 3)<br /> <br /> fec_decode_bufs() assumes that the parity bytes of the first RS codeword<br /> it decodes are never split across parity blocks.<br /> <br /> This assumption is false. Consider v-&gt;fec-&gt;block_size == 4096 &amp;&amp;<br /> v-&gt;fec-&gt;roots == 17 &amp;&amp; fio-&gt;nbufs == 1, for example. In that case, each<br /> call to fec_decode_bufs() consumes v-&gt;fec-&gt;roots * (fio-&gt;nbufs

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: check for nEPT/nNPT in slow flush hypercalls<br /> <br /> Checking is_guest_mode(vcpu) is incorrect, because translate_nested_gpa()<br /> is only valid if an L2 guest is running *with nested EPT/NPT enabled*.<br /> Instead use the same condition as translate_nested_gpa() itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo<br /> <br /> rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack<br /> without initialisation:<br /> <br /> struct ifla_vf_broadcast vf_broadcast;<br /> <br /> The struct contains a single fixed 32-byte field:<br /> <br /> /* include/uapi/linux/if_link.h */<br /> struct ifla_vf_broadcast {<br /> __u8 broadcast[32];<br /> };<br /> <br /> The function then copies dev-&gt;broadcast into it using dev-&gt;addr_len<br /> as the length:<br /> <br /> memcpy(vf_broadcast.broadcast, dev-&gt;broadcast, dev-&gt;addr_len);<br /> <br /> On Ethernet devices (the overwhelming majority of SR-IOV NICs)<br /> dev-&gt;addr_len is 6, so only the first 6 bytes of broadcast[] are<br /> written. The remaining 26 bytes retain whatever was previously on<br /> the kernel stack. The full struct is then handed to userspace via:<br /> <br /> nla_put(skb, IFLA_VF_BROADCAST,<br /> sizeof(vf_broadcast), &amp;vf_broadcast)<br /> <br /> leaking up to 26 bytes of uninitialised kernel stack per VF per<br /> RTM_GETLINK request, repeatable.<br /> <br /> The other vf_* structs in the same function are explicitly zeroed<br /> for exactly this reason - see the memset() calls for ivi,<br /> vf_vlan_info, node_guid and port_guid a few lines above.<br /> vf_broadcast was simply missed when it was added.<br /> <br /> Reachability: any unprivileged local process can open AF_NETLINK /<br /> NETLINK_ROUTE without capabilities and send RTM_GETLINK with an<br /> IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks<br /> each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per<br /> VF per request. Stack residue at this call site can include return<br /> addresses and transient sensitive data; KASAN with stack<br /> instrumentation, or KMSAN, will flag the nla_put() when reproduced.<br /> <br /> Zero the on-stack struct before the partial memcpy, matching the<br /> existing pattern used for the other vf_* structs in the same<br /> function.