Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: Fix possible oob access in mt7925_mac_write_txwi_80211()<br /> <br /> Check frame length before accessing the mgmt fields in<br /> mt7925_mac_write_txwi_80211 in order to avoid a possible oob access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: Compare MACs in constant time<br /> <br /> To prevent timing attacks, MAC comparisons need to be constant-time.<br /> Replace the memcmp() with the correct function, crypto_memneq().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: fix admin queue leak on controller reset<br /> <br /> When nvme_alloc_admin_tag_set() is called during a controller reset,<br /> a previous admin queue may still exist. Release it properly before<br /> allocating a new one to avoid orphaning the old queue.<br /> <br /> This fixes a regression introduced by commit 03b3bcd319b3 ("nvme: fix<br /> admin request_queue lifetime").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix stack-out-of-bounds write in devmap<br /> <br /> get_upper_ifindexes() iterates over all upper devices and writes their<br /> indices into an array without checking bounds.<br /> <br /> Also the callers assume that the max number of upper devices is<br /> MAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack,<br /> but that assumption is not correct and the number of upper devices could<br /> be larger than MAX_NEST_DEV (e.g., many macvlans), causing a<br /> stack-out-of-bounds write.<br /> <br /> Add a max parameter to get_upper_ifindexes() to avoid the issue.<br /> When there are too many upper devices, return -EOVERFLOW and abort the<br /> redirect.<br /> <br /> To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with<br /> an XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS.<br /> Then send a packet to the device to trigger the XDP redirect path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix error handling in slot reset<br /> <br /> If the device has not recovered after slot reset is called, it goes to<br /> out label for error handling. There it could make decision based on<br /> uninitialized hive pointer and could result in accessing an uninitialized<br /> list.<br /> <br /> Initialize the list and hive properly so that it handles the error<br /> situation and also releases the reset domain lock which is acquired<br /> during error_detected callback.<br /> <br /> (cherry picked from commit bb71362182e59caa227e4192da5a612b09349696)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: mcp251x: fix deadlock in error path of mcp251x_open<br /> <br /> The mcp251x_open() function call free_irq() in its error path with the<br /> mpc_lock mutex held. But if an interrupt already occurred the<br /> interrupt handler will be waiting for the mpc_lock and free_irq() will<br /> deadlock waiting for the handler to finish.<br /> <br /> This issue is similar to the one fixed in commit 7dd9c26bd6cf ("can:<br /> mcp251x: fix deadlock if an interrupt occurs during mcp251x_open") but<br /> for the error path.<br /> <br /> To solve this issue move the call to free_irq() after the lock is<br /> released. Setting `priv-&gt;force_quit = 1` beforehand ensure that the IRQ<br /> handler will exit right away once it acquired the lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock()<br /> <br /> Even though we check that we "should" be able to do lc_get_cumulative()<br /> while holding the device-&gt;al_lock spinlock, it may still fail,<br /> if some other code path decided to do lc_try_lock() with bad timing.<br /> <br /> If that happened, we logged "LOGIC BUG for enr=...",<br /> but still did not return an error.<br /> <br /> The rest of the code now assumed that this request has references<br /> for the relevant activity log extents.<br /> <br /> The implcations are that during an active resync, mutual exclusivity of<br /> resync versus application IO is not guaranteed. And a potential crash<br /> at this point may not realizs that these extents could have been target<br /> of in-flight IO and would need to be resynced just in case.<br /> <br /> Also, once the request completes, it will give up activity log references it<br /> does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put().<br /> <br /> Fix:<br /> <br /> Do not crash the kernel for a condition that is harmless during normal<br /> operation: also catch "e-&gt;refcnt == 0", not only "e == NULL"<br /> when being noisy about "al_complete_io() called on inactive extent %u\n".<br /> <br /> And do not try to be smart and "guess" whether something will work, then<br /> be surprised when it does not.<br /> Deal with the fact that it may or may not work. If it does not, remember a<br /> possible "partially in activity log" state (only possible for requests that<br /> cross extent boundaries), and return an error code from<br /> drbd_al_begin_io_nonblock().<br /> <br /> A latter call for the same request will then resume from where we left off.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata: cancel pending work after clearing deferred_qc<br /> <br /> Syzbot reported a WARN_ON() in ata_scsi_deferred_qc_work(), caused by<br /> ap-&gt;ops-&gt;qc_defer() returning non-zero before issuing the deferred qc.<br /> <br /> ata_scsi_schedule_deferred_qc() is called during each command completion.<br /> This function will check if there is a deferred QC, and if<br /> ap-&gt;ops-&gt;qc_defer() returns zero, meaning that it is possible to queue the<br /> deferred qc at this time (without being deferred), then it will queue the<br /> work which will issue the deferred qc.<br /> <br /> Once the work get to run, which can potentially be a very long time after<br /> the work was scheduled, there is a WARN_ON() if ap-&gt;ops-&gt;qc_defer() returns<br /> non-zero.<br /> <br /> While we hold the ap-&gt;lock both when assigning and clearing deferred_qc,<br /> and the work itself holds the ap-&gt;lock, the code currently does not cancel<br /> the work after clearing the deferred qc.<br /> <br /> This means that the following scenario can happen:<br /> 1) One or several NCQ commands are queued.<br /> 2) A non-NCQ command is queued, gets stored in ap-&gt;deferred_qc.<br /> 3) Last NCQ command gets completed, work is queued to issue the deferred<br /> qc.<br /> 4) Timeout or error happens, ap-&gt;deferred_qc is cleared. The queued work is<br /> currently NOT canceled.<br /> 5) Port is reset.<br /> 6) One or several NCQ commands are queued.<br /> 7) A non-NCQ command is queued, gets stored in ap-&gt;deferred_qc.<br /> 8) Work is finally run. Yet at this time, there is still NCQ commands in<br /> flight.<br /> <br /> The work in 8) really belongs to the non-NCQ command in 2), not to the<br /> non-NCQ command in 7). The reason why the work is executed when it is not<br /> supposed to, is because it was never canceled when ap-&gt;deferred_qc was<br /> cleared in 4). Thus, ensure that we always cancel the work after clearing<br /> ap-&gt;deferred_qc.<br /> <br /> Another potential fix would have been to let ata_scsi_deferred_qc_work() do<br /> nothing if ap-&gt;ops-&gt;qc_defer() returns non-zero. However, canceling the<br /> work when clearing ap-&gt;deferred_qc seems slightly more logical, as we hold<br /> the ap-&gt;lock when clearing ap-&gt;deferred_qc, so we know that the work cannot<br /> be holding the lock. (The function could be waiting for the lock, but that<br /> is okay since it will do nothing if ap-&gt;deferred_qc is not set.)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix crash in ethtool offline loopback test<br /> <br /> Since the conversion of ice to page pool, the ethtool loopback test<br /> crashes:<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000000c<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 1100f1067 P4D 0<br /> Oops: Oops: 0002 [#1] SMP NOPTI<br /> CPU: 23 UID: 0 PID: 5904 Comm: ethtool Kdump: loaded Not tainted 6.19.0-0.rc7.260128g1f97d9dcf5364.49.eln154.x86_64 #1 PREEMPT(lazy)<br /> Hardware name: [...]<br /> RIP: 0010:ice_alloc_rx_bufs+0x1cd/0x310 [ice]<br /> Code: 83 6c 24 30 01 66 41 89 47 08 0f 84 c0 00 00 00 41 0f b7 dc 48 8b 44 24 18 48 c1 e3 04 41 bb 00 10 00 00 48 8d 2c 18 8b 04 24 45 0c 41 8b 4d 00 49 d3 e3 44 3b 5c 24 24 0f 83 ac fe ff ff 44<br /> RSP: 0018:ff7894738aa1f768 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000700 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: ff16dcae79880200 R09: 0000000000000019<br /> R10: 0000000000000001 R11: 0000000000001000 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 0000000000000000 R15: ff16dcae6c670000<br /> FS: 00007fcf428850c0(0000) GS:ff16dcb149710000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000000000c CR3: 0000000121227005 CR4: 0000000000773ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ice_vsi_cfg_rxq+0xca/0x460 [ice]<br /> ice_vsi_cfg_rxqs+0x54/0x70 [ice]<br /> ice_loopback_test+0xa9/0x520 [ice]<br /> ice_self_test+0x1b9/0x280 [ice]<br /> ethtool_self_test+0xe5/0x200<br /> __dev_ethtool+0x1106/0x1a90<br /> dev_ethtool+0xbe/0x1a0<br /> dev_ioctl+0x258/0x4c0<br /> sock_do_ioctl+0xe3/0x130<br /> __x64_sys_ioctl+0xb9/0x100<br /> do_syscall_64+0x7c/0x700<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [...]<br /> <br /> It crashes because we have not initialized libeth for the rx ring.<br /> <br /> Fix it by treating ICE_VSI_LB VSIs slightly more like normal PF VSIs and<br /> letting them have a q_vector. It&amp;#39;s just a dummy, because the loopback<br /> test does not use interrupts, but it contains a napi struct that can be<br /> passed to libeth_rx_fq_create() called from ice_vsi_cfg_rxq() -&gt;<br /> ice_rxq_pp_create().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/efi: defer freeing of boot services memory<br /> <br /> efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE<br /> and EFI_BOOT_SERVICES_DATA using memblock_free_late().<br /> <br /> There are two issue with that: memblock_free_late() should be used for<br /> memory allocated with memblock_alloc() while the memory reserved with<br /> memblock_reserve() should be freed with free_reserved_area().<br /> <br /> More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y<br /> efi_free_boot_services() is called before deferred initialization of the<br /> memory map is complete.<br /> <br /> Benjamin Herrenschmidt reports that this causes a leak of ~140MB of<br /> RAM on EC2 t3a.nano instances which only have 512MB or RAM.<br /> <br /> If the freed memory resides in the areas that memory map for them is<br /> still uninitialized, they won&amp;#39;t be actually freed because<br /> memblock_free_late() calls memblock_free_pages() and the latter skips<br /> uninitialized pages.<br /> <br /> Using free_reserved_area() at this point is also problematic because<br /> __free_page() accesses the buddy of the freed page and that again might<br /> end up in uninitialized part of the memory map.<br /> <br /> Delaying the entire efi_free_boot_services() could be problematic<br /> because in addition to freeing boot services memory it updates<br /> efi.memmap without any synchronization and that&amp;#39;s undesirable late in<br /> boot when there is concurrency.<br /> <br /> More robust approach is to only defer freeing of the EFI boot services<br /> memory.<br /> <br /> Split efi_free_boot_services() in two. First efi_unmap_boot_services()<br /> collects ranges that should be freed into an array then<br /> efi_free_boot_services() later frees them after deferred init is complete.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_pipapo: split gc into unlink and reclaim phase<br /> <br /> Yiming Qian reports Use-after-free in the pipapo set type:<br /> Under a large number of expired elements, commit-time GC can run for a very<br /> long time in a non-preemptible context, triggering soft lockup warnings and<br /> RCU stall reports (local denial of service).<br /> <br /> We must split GC in an unlink and a reclaim phase.<br /> <br /> We cannot queue elements for freeing until pointers have been swapped.<br /> Expired elements are still exposed to both the packet path and userspace<br /> dumpers via the live copy of the data structure.<br /> <br /> call_rcu() does not protect us: dump operations or element lookups starting<br /> after call_rcu has fired can still observe the free&amp;#39;d element, unless the<br /> commit phase has made enough progress to swap the clone and live pointers<br /> before any new reader has picked up the old version.<br /> <br /> This a similar approach as done recently for the rbtree backend in commit<br /> 35f83a75529a ("netfilter: nft_set_rbtree: don&amp;#39;t gc elements on insert").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/queue: Call fini on exec queue creation fail<br /> <br /> Every call to queue init should have a corresponding fini call.<br /> Skipping this would mean skipping removal of the queue from GuC list<br /> (which is part of guc_id allocation). A damaged queue stored in<br /> exec_queue_lookup list would lead to invalid memory reference,<br /> sooner or later.<br /> <br /> Call fini to free guc_id. This must be done before any internal<br /> LRCs are freed.<br /> <br /> Since the finalization with this extra call became very similar to<br /> __xe_exec_queue_fini(), reuse that. To make this reuse possible,<br /> alter xe_lrc_put() so it can survive NULL parameters, like other<br /> similar functions.<br /> <br /> v2: Reuse _xe_exec_queue_fini(). Make xe_lrc_put() aware of NULLs.<br /> <br /> (cherry picked from commit 393e5fea6f7d7054abc2c3d97a4cfe8306cd6079)