Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fix statistics allocation<br /> <br /> The controller per-cpu statistics is not allocated until after the<br /> controller has been registered with driver core, which leaves a window<br /> where accessing the sysfs attributes can trigger a NULL-pointer<br /> dereference.<br /> <br /> Fix this by moving the statistics allocation to controller allocation<br /> while tying its lifetime to that of the controller (rather than using<br /> implicit devres).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/dmc: Fix an unlikely NULL pointer deference at probe<br /> <br /> intel_dmc_update_dc6_allowed_count() oopses when DMC hasn&amp;#39;t been<br /> initialized, and dmc is thus NULL.<br /> <br /> That would be the case when the call path is<br /> intel_power_domains_init_hw() -&gt; {skl,bxt,icl}_display_core_init() -&gt;<br /> gen9_set_dc_state() -&gt; intel_dmc_update_dc6_allowed_count(), as<br /> intel_power_domains_init_hw() is called *before* intel_dmc_init().<br /> <br /> However, gen9_set_dc_state() calls intel_dmc_update_dc6_allowed_count()<br /> conditionally, depending on the current and target DC states. At probe,<br /> the target is disabled, but if DC6 is enabled, the function is called,<br /> and an oops follows. Apparently it&amp;#39;s quite unlikely that DC6 is enabled<br /> at probe, as we haven&amp;#39;t seen this failure mode before.<br /> <br /> It is also strange to have DC6 enabled at boot, since that would require<br /> the DMC firmware (loaded by BIOS); the BIOS loading the DMC firmware and<br /> the driver stopping / reprogramming the firmware is a poorly specified<br /> sequence and as such unlikely an intentional BIOS behaviour. It&amp;#39;s more<br /> likely that BIOS is leaving an unintentionally enabled DC6 HW state<br /> behind (without actually loading the required DMC firmware for this).<br /> <br /> The tracking of the DC6 allowed counter only works if starting /<br /> stopping the counter depends on the _SW_ DC6 state vs. the current _HW_<br /> DC6 state (since stopping the counter requires the DC5 counter captured<br /> when the counter was started). Thus, using the HW DC6 state is incorrect<br /> and it also leads to the above oops. Fix both issues by using the SW DC6<br /> state for the tracking.<br /> <br /> This is v2 of the fix originally sent by Jani, updated based on the<br /> first Link: discussion below.<br /> <br /> (cherry picked from commit 2344b93af8eb5da5d496b4e0529d35f0f559eaf0)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Synchronize interrupts before suspending the GPU<br /> <br /> The runtime PM suspend callback doesn&amp;#39;t know whether the IRQ handler is<br /> in progress on a different CPU core and doesn&amp;#39;t wait for it to finish.<br /> <br /> Depending on timing, the IRQ handler could be running while the GPU is<br /> suspended, leading to kernel crashes when trying to access GPU<br /> registers. See example signature below.<br /> <br /> In a power off sequence initiated by the runtime PM suspend callback,<br /> wait for any IRQ handlers in progress on other CPU cores to finish, by<br /> calling synchronize_irq().<br /> <br /> At the same time, remove the runtime PM resume/put calls in the threaded<br /> IRQ handler. On top of not being the right approach to begin with, and<br /> being at the wrong place as they should have wrapped all GPU register<br /> accesses, the driver would hit a deadlock between synchronize_irq()<br /> being called from a runtime PM suspend callback, holding the device<br /> power lock, and the resume callback requiring the same.<br /> <br /> Example crash signature on a TI AM68 SK platform:<br /> <br /> [ 337.241218] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError<br /> [ 337.241239] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT<br /> [ 337.241246] Tainted: [M]=MACHINE_CHECK<br /> [ 337.241249] Hardware name: Texas Instruments AM68 SK (DT)<br /> [ 337.241252] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 337.241256] pc : pvr_riscv_irq_pending+0xc/0x24<br /> [ 337.241277] lr : pvr_device_irq_thread_handler+0x64/0x310<br /> [ 337.241282] sp : ffff800085b0bd30<br /> [ 337.241284] x29: ffff800085b0bd50 x28: ffff0008070d9eab x27: ffff800083a5ce10<br /> [ 337.241291] x26: ffff000806e48f80 x25: ffff0008070d9eac x24: 0000000000000000<br /> [ 337.241296] x23: ffff0008068e9bf0 x22: ffff0008068e9bd0 x21: ffff800085b0bd30<br /> [ 337.241301] x20: ffff0008070d9e00 x19: ffff0008068e9000 x18: 0000000000000001<br /> [ 337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40<br /> [ 337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a<br /> [ 337.241314] x11: 00000000000000c0 x10: 0000000000000af0 x9 : ffff800085b0bd00<br /> [ 337.241318] x8 : ffff0008071175d0 x7 : 000000000000b955 x6 : 0000000000000003<br /> [ 337.241323] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 0000000000000000<br /> [ 337.241327] x2 : ffff800080e39d20 x1 : ffff800080e3fc48 x0 : 0000000000000000<br /> [ 337.241333] Kernel panic - not syncing: Asynchronous SError Interrupt<br /> [ 337.241337] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT<br /> [ 337.241342] Tainted: [M]=MACHINE_CHECK<br /> [ 337.241343] Hardware name: Texas Instruments AM68 SK (DT)<br /> [ 337.241345] Call trace:<br /> [ 337.241348] show_stack+0x18/0x24 (C)<br /> [ 337.241357] dump_stack_lvl+0x60/0x80<br /> [ 337.241364] dump_stack+0x18/0x24<br /> [ 337.241368] vpanic+0x124/0x2ec<br /> [ 337.241373] abort+0x0/0x4<br /> [ 337.241377] add_taint+0x0/0xbc<br /> [ 337.241384] arm64_serror_panic+0x70/0x80<br /> [ 337.241389] do_serror+0x3c/0x74<br /> [ 337.241392] el1h_64_error_handler+0x30/0x48<br /> [ 337.241400] el1h_64_error+0x6c/0x70<br /> [ 337.241404] pvr_riscv_irq_pending+0xc/0x24 (P)<br /> [ 337.241410] irq_thread_fn+0x2c/0xb0<br /> [ 337.241416] irq_thread+0x170/0x334<br /> [ 337.241421] kthread+0x12c/0x210<br /> [ 337.241428] ret_from_fork+0x10/0x20<br /> [ 337.241434] SMP: stopping secondary CPUs<br /> [ 337.241451] Kernel Offset: disabled<br /> [ 337.241453] CPU features: 0x040000,02002800,20002001,0400421b<br /> [ 337.241456] Memory Limit: none<br /> [ 337.457921] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Fix deadlock in soft reset sequence<br /> <br /> The soft reset sequence is currently executed from the threaded IRQ<br /> handler, hence it cannot call disable_irq() which internally waits<br /> for IRQ handlers, i.e. itself, to complete.<br /> <br /> Use disable_irq_nosync() during a soft reset instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWN<br /> <br /> uart_write_room() and uart_write() behave inconsistently when<br /> xmit_buf is NULL (which happens for PORT_UNKNOWN ports that were<br /> never properly initialized):<br /> <br /> - uart_write_room() returns kfifo_avail() which can be &gt; 0<br /> - uart_write() checks xmit_buf and returns 0 if NULL<br /> <br /> This inconsistency causes an infinite loop in drivers that rely on<br /> tty_write_room() to determine if they can write:<br /> <br /> while (tty_write_room(tty) &gt; 0) {<br /> written = tty-&gt;ops-&gt;write(...);<br /> // written is always 0, loop never exits<br /> }<br /> <br /> For example, caif_serial&amp;#39;s handle_tx() enters an infinite loop when<br /> used with PORT_UNKNOWN serial ports, causing system hangs.<br /> <br /> Fix by making uart_write_room() also check xmit_buf and return 0 if<br /> it&amp;#39;s NULL, consistent with uart_write().<br /> <br /> Reproducer: https://gist.github.com/mrpre/d9a694cc0e19828ee3bc3b37983fde13

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Limit BO list entry count to prevent resource exhaustion<br /> <br /> Userspace can pass an arbitrary number of BO list entries via the<br /> bo_number field. Although the previous multiplication overflow check<br /> prevents out-of-bounds allocation, a large number of entries could still<br /> cause excessive memory allocation (up to potentially gigabytes) and<br /> unnecessarily long list processing times.<br /> <br /> Introduce a hard limit of 128k entries per BO list, which is more than<br /> sufficient for any realistic use case (e.g., a single list containing all<br /> buffers in a large scene). This prevents memory exhaustion attacks and<br /> ensures predictable performance.<br /> <br /> Return -EINVAL if the requested entry count exceeds the limit<br /> <br /> (cherry picked from commit 688b87d39e0aa8135105b40dc167d74b5ada5332)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Open-code GGTT MMIO access protection<br /> <br /> GGTT MMIO access is currently protected by hotplug (drm_dev_enter),<br /> which works correctly when the driver loads successfully and is later<br /> unbound or unloaded. However, if driver load fails, this protection is<br /> insufficient because drm_dev_unplug() is never called.<br /> <br /> Additionally, devm release functions cannot guarantee that all BOs with<br /> GGTT mappings are destroyed before the GGTT MMIO region is removed, as<br /> some BOs may be freed asynchronously by worker threads.<br /> <br /> To address this, introduce an open-coded flag, protected by the GGTT<br /> lock, that guards GGTT MMIO access. The flag is cleared during the<br /> dev_fini_ggtt devm release function to ensure MMIO access is disabled<br /> once teardown begins.<br /> <br /> (cherry picked from commit 4f3a998a173b4325c2efd90bdadc6ccd3ad9a431)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: log new dentries when logging parent dir of a conflicting inode<br /> <br /> If we log the parent directory of a conflicting inode, we are not logging<br /> the new dentries of the directory, so when we finish we have the parent<br /> directory&amp;#39;s inode marked as logged but we did not log its new dentries.<br /> As a consequence if the parent directory is explicitly fsynced later and<br /> it does not have any new changes since we logged it, the fsync is a no-op<br /> and after a power failure the new dentries are missing.<br /> <br /> Example scenario:<br /> <br /> $ mkdir foo<br /> <br /> $ sync<br /> <br /> $rmdir foo<br /> <br /> $ mkdir dir1<br /> $ mkdir dir2<br /> <br /> # A file with the same name and parent as the directory we just deleted<br /> # and was persisted in a past transaction. So the deleted directory&amp;#39;s<br /> # inode is a conflicting inode of this new file&amp;#39;s inode.<br /> $ touch foo<br /> <br /> $ ln foo dir2/link<br /> <br /> # The fsync on dir2 will log the parent directory (".") because the<br /> # conflicting inode (deleted directory) does not exists anymore, but it<br /> # it does not log its new dentries (dir1).<br /> $ xfs_io -c "fsync" dir2<br /> <br /> # This fsync on the parent directory is no-op, since the previous fsync<br /> # logged it (but without logging its new dentries).<br /> $ xfs_io -c "fsync" .<br /> <br /> <br /> <br /> # After log replay dir1 is missing.<br /> <br /> Fix this by ensuring we log new dir dentries whenever we log the parent<br /> directory of a no longer existing conflicting inode.<br /> <br /> A test case for fstests will follow soon.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: microchip: mpfs: Fix memory leak in mpfs_sys_controller_probe()<br /> <br /> In mpfs_sys_controller_probe(), if of_get_mtd_device_by_node() fails,<br /> the function returns immediately without freeing the allocated memory<br /> for sys_controller, leading to a memory leak.<br /> <br /> Fix this by jumping to the out_free label to ensure the memory is<br /> properly freed.<br /> <br /> Also, consolidate the error handling for the mbox_request_channel()<br /> failure case to use the same label.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: fsl: qbman: fix race condition in qman_destroy_fq<br /> <br /> When QMAN_FQ_FLAG_DYNAMIC_FQID is set, there&amp;#39;s a race condition between<br /> fq_table[fq-&gt;idx] state and freeing/allocating from the pool and<br /> WARN_ON(fq_table[fq-&gt;idx]) in qman_create_fq() gets triggered.<br /> <br /> Indeed, we can have:<br /> Thread A Thread B<br /> qman_destroy_fq() qman_create_fq()<br /> qman_release_fqid()<br /> qman_shutdown_fq()<br /> gen_pool_free()<br /> -- At this point, the fqid is available again --<br /> qman_alloc_fqid()<br /> -- so, we can get the just-freed fqid in thread B --<br /> fq-&gt;fqid = fqid;<br /> fq-&gt;idx = fqid * 2;<br /> WARN_ON(fq_table[fq-&gt;idx]);<br /> fq_table[fq-&gt;idx] = fq;<br /> fq_table[fq-&gt;idx] = NULL;<br /> <br /> And adding some logs between qman_release_fqid() and<br /> fq_table[fq-&gt;idx] = NULL makes the WARN_ON() trigger a lot more.<br /> <br /> To prevent that, ensure that fq_table[fq-&gt;idx] is set to NULL before<br /> gen_pool_free() is called by using smp_wmb().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: HIDP: Fix possible UAF<br /> <br /> This fixes the following trace caused by not dropping l2cap_conn<br /> reference when user-&gt;remove callback is called:<br /> <br /> [ 97.809249] l2cap_conn_free: freeing conn ffff88810a171c00<br /> [ 97.809907] CPU: 1 UID: 0 PID: 1419 Comm: repro_standalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy)<br /> [ 97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014<br /> [ 97.809947] Call Trace:<br /> [ 97.809954] <br /> [ 97.809961] dump_stack_lvl (lib/dump_stack.c:122)<br /> [ 97.809990] l2cap_conn_free (net/bluetooth/l2cap_core.c:1808)<br /> [ 97.810017] l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798)<br /> [ 97.810055] l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (discriminator 1) net/bluetooth/l2cap_core.c:7340 (discriminator 1))<br /> [ 97.810086] ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341)<br /> [ 97.810117] hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (discriminator 2) net/bluetooth/hci_conn.c:2644 (discriminator 2))<br /> [ 97.810148] hci_dev_close_sync (net/bluetooth/hci_sync.c:5360)<br /> [ 97.810180] ? __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285)<br /> [ 97.810212] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810242] ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5))<br /> [ 97.810267] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810290] ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752)<br /> [ 97.810320] hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716)<br /> [ 97.810346] vhci_release (drivers/bluetooth/hci_vhci.c:691)<br /> [ 97.810375] ? __pfx_vhci_release (drivers/bluetooth/hci_vhci.c:678)<br /> [ 97.810404] __fput (fs/file_table.c:470)<br /> [ 97.810430] task_work_run (kernel/task_work.c:235)<br /> [ 97.810451] ? __pfx_task_work_run (kernel/task_work.c:201)<br /> [ 97.810472] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810495] ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5))<br /> [ 97.810527] do_exit (kernel/exit.c:972)<br /> [ 97.810547] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810574] ? __pfx_do_exit (kernel/exit.c:897)<br /> [ 97.810594] ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6))<br /> [ 97.810616] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810639] ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4))<br /> [ 97.810664] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810688] ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1))<br /> [ 97.810721] do_group_exit (kernel/exit.c:1093)<br /> [ 97.810745] get_signal (kernel/signal.c:3007 (discriminator 1))<br /> [ 97.810772] ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366)<br /> [ 97.810803] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810826] ? vfs_read (fs/read_write.c:555)<br /> [ 97.810854] ? __pfx_get_signal (kernel/signal.c:2800)<br /> [ 97.810880] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810905] ? __pfx_vfs_read (fs/read_write.c:555)<br /> [ 97.810932] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 97.810960] arch_do_signal_or_restart (arch/<br /> ---truncated---