Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 8021q: delete cleared egress QoS mappings<br /> <br /> vlan_dev_set_egress_priority() currently keeps cleared egress<br /> priority mappings in the hash as tombstones. Repeated set/clear cycles<br /> with distinct skb priorities therefore accumulate mapping nodes until<br /> device teardown and leak memory.<br /> <br /> Delete mappings when vlan_prio is cleared instead of keeping tombstones.<br /> Now that the egress mapping lists are RCU protected, the node can be<br /> unlinked safely and freed after a grace period.

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 /> wifi: mt76: mt7921: fix a potential clc buffer length underflow<br /> <br /> The buf_len is used to limit the iterations for retrieving the country<br /> power setting and may underflow under certain conditions due to changes<br /> in the power table in CLC.<br /> <br /> This underflow leads to an almost infinite loop or an invalid power<br /> setting resulting in driver initialization failure.

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 /> smb: client: use kzalloc to zero-initialize security descriptor buffer<br /> <br /> Commit 62e7dd0a39c2d ("smb: common: change the data type of num_aces<br /> to le16") split struct smb_acl&amp;#39;s __le32 num_aces field into __le16<br /> num_aces and __le16 reserved. The reserved field corresponds to Sbz2<br /> in the MS-DTYP ACL wire format, which must be zero [1].<br /> <br /> When building an ACL descriptor in build_sec_desc(), we are using a<br /> kmalloc()&amp;#39;ed descriptor buffer and writing the fields explicitly using<br /> le16() writes now. This never writes to the 2 byte reserved field,<br /> leaving it as uninitialized heap data.<br /> <br /> When the reserved field happens to contain non-zero slab garbage,<br /> Samba rejects the security descriptor with "ndr_pull_security_descriptor<br /> failed: Range Error", causing chmod to fail with EINVAL.<br /> <br /> Change kmalloc() to kzalloc() to ensure the entire buffer is<br /> zero-initialized.<br /> <br /> <br /> [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btmtk: validate WMT event SKB length before struct access<br /> <br /> btmtk_usb_hci_wmt_sync() casts the WMT event response SKB data to<br /> struct btmtk_hci_wmt_evt (7 bytes) and struct btmtk_hci_wmt_evt_funcc<br /> (9 bytes) without first checking that the SKB contains enough data.<br /> A short firmware response causes out-of-bounds reads from SKB tailroom.<br /> <br /> Use skb_pull_data() to validate and advance past the base WMT event<br /> header. For the FUNC_CTRL case, pull the additional status field bytes<br /> before accessing them.

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 /> wifi: mac80211: remove station if connection prep fails<br /> <br /> If connection preparation fails for MLO connections, then the<br /> interface is completely reset to non-MLD. In this case, we must<br /> not keep the station since it&amp;#39;s related to the link of the vif<br /> being removed. Delete an existing station. Any "new_sta" is<br /> already being removed, so that doesn&amp;#39;t need changes.<br /> <br /> This fixes a use-after-free/double-free in debugfs if that&amp;#39;s<br /> enabled, because a vif going from MLD (and to MLD, but that&amp;#39;s<br /> not relevant here) recreates its entire debugfs.

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--.