Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: fsl_xcvr: Revert fix missing lock in fsl_xcvr_mode_put()<br /> <br /> This reverts commit f51424872760 ("ASoC: fsl_xcvr: fix missing lock in fsl_xcvr_mode_put()").<br /> <br /> The original patch attempted to acquire the card-&gt;controls_rwsem lock in<br /> fsl_xcvr_mode_put(). However, this function is called from the upper ALSA<br /> core function snd_ctl_elem_write(), which already holds the write lock on<br /> controls_rwsem for the whole put operation. So there is no need to simply<br /> hold the lock for fsl_xcvr_activate_ctl() again.<br /> <br /> Acquiring the read lock while holding the write lock in the same thread<br /> results in a deadlock and a hung task, as reported by Alexander Stein.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix out-of-bounds stream encoder index v3<br /> <br /> eng_id can be negative and that stream_enc_regs[]<br /> can be indexed out of bounds.<br /> <br /> eng_id is used directly as an index into stream_enc_regs[], which has<br /> only 5 entries. When eng_id is 5 (ENGINE_ID_DIGF) or negative, this can<br /> access memory past the end of the array.<br /> <br /> Add a bounds check using ARRAY_SIZE() before using eng_id as an index.<br /> The unsigned cast also rejects negative values.<br /> <br /> This avoids out-of-bounds access.<br /> <br /> Fixes the below smatch error:<br /> dcn*_resource.c: stream_encoder_create() may index<br /> stream_enc_regs[eng_id] out of bounds (size 5).<br /> <br /> drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn351/dcn351_resource.c<br /> 1246 static struct stream_encoder *dcn35_stream_encoder_create(<br /> 1247 enum engine_id eng_id,<br /> 1248 struct dc_context *ctx)<br /> 1249 {<br /> <br /> ...<br /> <br /> 1255<br /> 1256 /* Mapping of VPG, AFMT, DME register blocks to DIO block instance */<br /> 1257 if (eng_id

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/pf: Fix sysfs initialization<br /> <br /> In case of devm_add_action_or_reset() failure the provided cleanup<br /> action will be run immediately on the not yet initialized kobject.<br /> This may lead to errors like:<br /> <br /> [ ] kobject: &amp;#39;(null)&amp;#39; (ff110001393608e0): is not initialized, yet kobject_put() is being called.<br /> [ ] WARNING: lib/kobject.c:734 at kobject_put+0xd9/0x250, CPU#0: kworker/0:0/9<br /> [ ] RIP: 0010:kobject_put+0xdf/0x250<br /> [ ] Call Trace:<br /> [ ] xe_sriov_pf_sysfs_init+0x21/0x100 [xe]<br /> [ ] xe_sriov_pf_init_late+0x87/0x2b0 [xe]<br /> [ ] xe_sriov_init_late+0x5f/0x2c0 [xe]<br /> [ ] xe_device_probe+0x5f2/0xc20 [xe]<br /> [ ] xe_pci_probe+0x396/0x610 [xe]<br /> [ ] local_pci_probe+0x47/0xb0<br /> <br /> [ ] refcount_t: underflow; use-after-free.<br /> [ ] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x68/0xb0, CPU#0: kworker/0:0/9<br /> [ ] RIP: 0010:refcount_warn_saturate+0x68/0xb0<br /> [ ] Call Trace:<br /> [ ] kobject_put+0x174/0x250<br /> [ ] xe_sriov_pf_sysfs_init+0x21/0x100 [xe]<br /> [ ] xe_sriov_pf_init_late+0x87/0x2b0 [xe]<br /> [ ] xe_sriov_init_late+0x5f/0x2c0 [xe]<br /> [ ] xe_device_probe+0x5f2/0xc20 [xe]<br /> [ ] xe_pci_probe+0x396/0x610 [xe]<br /> [ ] local_pci_probe+0x47/0xb0<br /> <br /> Fix that by calling kobject_init() and kobject_add() separately<br /> and register cleanup action after the kobject is initialized.<br /> <br /> Also make this cleanup registration a part of the create helper to<br /> fix another mistake, as in the loop we were wrongly passing parent<br /> kobject while registering cleanup action, and this resulted in some<br /> undetected leaks.<br /> <br /> (cherry picked from commit 98b16727f07e26a5d4de84d88805ce7ffcfdd324)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore/ram: fix buffer overflow in persistent_ram_save_old()<br /> <br /> persistent_ram_save_old() can be called multiple times for the same<br /> persistent_ram_zone (e.g., via ramoops_pstore_read -&gt; ramoops_get_next_prz<br /> for PSTORE_TYPE_DMESG records).<br /> <br /> Currently, the function only allocates prz-&gt;old_log when it is NULL,<br /> but it unconditionally updates prz-&gt;old_log_size to the current buffer<br /> size and then performs memcpy_fromio() using this new size. If the<br /> buffer size has grown since the first allocation (which can happen<br /> across different kernel boot cycles), this leads to:<br /> <br /> 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls<br /> 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer<br /> using the incorrect (larger) old_log_size<br /> <br /> The KASAN splat would look similar to:<br /> BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x...<br /> Read of size N at addr ... by task ...<br /> <br /> The conditions are likely extremely hard to hit:<br /> <br /> 0. Crash with a ramoops write of less-than-record-max-size bytes.<br /> 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash,<br /> allocates old_log with size X<br /> 2. Crash handler registered, timer started (if pstore_update_ms &gt;= 0)<br /> 3. Oops happens (non-fatal, system continues)<br /> 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (&gt;X)<br /> 5. pstore_new_entry = 1, pstore_timer_kick() called<br /> 6. System continues running (not a panic oops)<br /> 7. Timer fires after pstore_update_ms milliseconds<br /> 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1)<br /> 9. ramoops_get_next_prz() → persistent_ram_save_old()<br /> 10. buffer_size() returns Y, but old_log is X bytes<br /> 11. Y &gt; X: memcpy_fromio() overflows heap<br /> <br /> Requirements:<br /> - a prior crash record exists that did not fill the record size<br /> (almost impossible since the crash handler writes as much as it<br /> can possibly fit into the record, capped by max record size and<br /> the kmsg buffer almost always exceeds the max record size)<br /> - pstore_update_ms &gt;= 0 (disabled by default)<br /> - Non-fatal oops (system survives)<br /> <br /> Free and reallocate the buffer when the new size differs from the<br /> previously allocated size. This ensures old_log always has sufficient<br /> space for the data being copied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> AppArmor: Allow apparmor to handle unaligned dfa tables<br /> <br /> The dfa tables can originate from kernel or userspace and 8-byte alignment<br /> isn&amp;#39;t always guaranteed and as such may trigger unaligned memory accesses<br /> on various architectures. Resulting in the following<br /> <br /> [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720<br /> [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom<br /> sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common<br /> [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE<br /> [   74.536543] Call Trace:<br /> [   74.568561] [] dump_stack+0x8/0x18<br /> [   74.633757] [] __warn+0xd8/0x100<br /> [   74.696664] [] warn_slowpath_fmt+0x34/0x74<br /> [   74.771006] [] aa_dfa_unpack+0x6cc/0x720<br /> [   74.843062] [] unpack_pdb+0xbc/0x7e0<br /> [   74.910545] [] unpack_profile+0xbe0/0x1300<br /> [   74.984888] [] aa_unpack+0xe0/0x6a0<br /> [   75.051226] [] aa_replace_profiles+0x64/0x1160<br /> [   75.130144] [] policy_update+0xf0/0x280<br /> [   75.201057] [] profile_replace+0xa8/0x100<br /> [   75.274258] [] vfs_write+0x90/0x420<br /> [   75.340594] [] ksys_write+0x4c/0xe0<br /> [   75.406932] [] sys_write+0x14/0x40<br /> [   75.472126] [] linux_sparc_syscall+0x34/0x44<br /> [   75.548802] ---[ end trace 0000000000000000 ]---<br /> [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned.<br /> [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720<br /> <br /> Work around it by using the get_unaligned_xx() helpers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: fsl-edma: don&amp;#39;t explicitly disable clocks in .remove()<br /> <br /> The clocks in fsl_edma_engine::muxclk are allocated and enabled with<br /> devm_clk_get_enabled(), which automatically cleans these resources up,<br /> but these clocks are also manually disabled in fsl_edma_remove(). This<br /> causes warnings on driver removal for each clock:<br /> <br /> edma_module already disabled<br /> WARNING: CPU: 0 PID: 418 at drivers/clk/clk.c:1200 clk_core_disable+0x198/0x1c8<br /> [...]<br /> Call trace:<br /> clk_core_disable+0x198/0x1c8 (P)<br /> clk_disable+0x34/0x58<br /> fsl_edma_remove+0x74/0xe8 [fsl_edma]<br /> [...]<br /> ---[ end trace 0000000000000000 ]---<br /> edma_module already unprepared<br /> WARNING: CPU: 0 PID: 418 at drivers/clk/clk.c:1059 clk_core_unprepare+0x1f8/0x220<br /> [...]<br /> Call trace:<br /> clk_core_unprepare+0x1f8/0x220 (P)<br /> clk_unprepare+0x34/0x58<br /> fsl_edma_remove+0x7c/0xe8 [fsl_edma]<br /> [...]<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Fix these warnings by removing the unnecessary fsl_disable_clocks() call<br /> in fsl_edma_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS/localio: prevent direct reclaim recursion into NFS via nfs_writepages<br /> <br /> LOCALIO is an NFS loopback mount optimization that avoids using the<br /> network for READ, WRITE and COMMIT if the NFS client and server are<br /> determined to be on the same system. But because LOCALIO is still<br /> fundamentally "just NFS loopback mount" it is susceptible to recursion<br /> deadlock via direct reclaim, e.g.: NFS LOCALIO down to XFS and then<br /> back into NFS via nfs_writepages.<br /> <br /> Fix LOCALIO&amp;#39;s potential for direct reclaim deadlock by ensuring that<br /> all its page cache allocations are done from GFP_NOFS context.<br /> <br /> Thanks to Ben Coddington for pointing out commit ad22c7a043c2 ("xfs:<br /> prevent stack overflows from page cache allocation").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clocksource/drivers/timer-sp804: Fix an Oops when read_current_timer is called on ARM32 platforms where the SP804 is not registered as the sched_clock.<br /> <br /> On SP804, the delay timer shares the same clkevt instance with<br /> sched_clock. On some platforms, when<br /> sp804_clocksource_and_sched_clock_init is called with use_sched_clock<br /> not set to 1, sched_clkevt is not properly initialized. However,<br /> sp804_register_delay_timer is invoked unconditionally, and<br /> read_current_timer() subsequently calls sp804_read on an uninitialized<br /> sched_clkevt, leading to a kernel Oops when accessing<br /> sched_clkevt-&gt;value.<br /> <br /> Declare a dedicated clkevt instance exclusively for delay timer,<br /> instead of sharing the same clkevt with sched_clock. This ensures<br /> that read_current_timer continues to work correctly regardless of<br /> whether SP804 is selected as the sched_clock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: cdev: Avoid NULL dereference in linehandle_create()<br /> <br /> In linehandle_create(), there is a statement like this:<br /> retain_and_null_ptr(lh);<br /> <br /> Soon after, there is a debug printout that dereferences "lh", which<br /> will crash things.<br /> <br /> Avoid the crash by using handlereq.lines, which is the same value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> procfs: fix missing RCU protection when reading real_parent in do_task_stat()<br /> <br /> When reading /proc/[pid]/stat, do_task_stat() accesses task-&gt;real_parent<br /> without proper RCU protection, which leads to:<br /> <br /> cpu 0 cpu 1<br /> ----- -----<br /> do_task_stat<br /> var = task-&gt;real_parent<br /> release_task<br /> call_rcu(delayed_put_task_struct)<br /> task_tgid_nr_ns(var)<br /> rcu_read_lock real_parent!<br /> task_pid_ptr real_parent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix block_group_tree dirty_list corruption<br /> <br /> When the incompat flag EXTENT_TREE_V2 is set, we unconditionally add the<br /> block group tree to the switch_commits list before calling<br /> switch_commit_roots, as we do for the tree root and the chunk root.<br /> However, the block group tree uses normal root dirty tracking and in any<br /> transaction that does an allocation and dirties a block group, the block<br /> group root will already be linked to a list by the dirty_list field and<br /> this use of list_add_tail() is invalid and corrupts the prev/next<br /> members of block_group_root-&gt;dirty_list.<br /> <br /> This is apparent on a subsequent list_del on the prev if we enable<br /> CONFIG_DEBUG_LIST:<br /> <br /> [32.1571] ------------[ cut here ]------------<br /> [32.1572] list_del corruption. next-&gt;prev should beffff958890202538, but was ffff9588992bd538. (next=ffff958890201538)<br /> [32.1575] WARNING: lib/list_debug.c:65 at 0x0, CPU#3: sync/607<br /> [32.1583] CPU: 3 UID: 0 PID: 607 Comm: sync Not tainted 6.18.0 #24PREEMPT(none)<br /> [32.1585] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.17.0-4.fc41 04/01/2014<br /> [32.1587] RIP: 0010:__list_del_entry_valid_or_report+0x108/0x120<br /> [32.1593] RSP: 0018:ffffaa288287fdd0 EFLAGS: 00010202<br /> [32.1594] RAX: 0000000000000001 RBX: ffff95889326e800 RCX:ffff958890201538<br /> [32.1596] RDX: ffff9588992bd538 RSI: ffff958890202538 RDI:ffffffff82a41e00<br /> [32.1597] RBP: ffff958890202538 R08: ffffffff828fc1e8 R09:00000000ffffefff<br /> [32.1599] R10: ffffffff8288c200 R11: ffffffff828e4200 R12:ffff958890201538<br /> [32.1601] R13: ffff95889326e958 R14: ffff958895c24000 R15:ffff958890202538<br /> [32.1603] FS: 00007f0c28eb5740(0000) GS:ffff958af2bd2000(0000)knlGS:0000000000000000<br /> [32.1605] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [32.1607] CR2: 00007f0c28e8a3cc CR3: 0000000109942005 CR4:0000000000370ef0<br /> [32.1609] Call Trace:<br /> [32.1610] <br /> [32.1611] switch_commit_roots+0x82/0x1d0 [btrfs]<br /> [32.1615] btrfs_commit_transaction+0x968/0x1550 [btrfs]<br /> [32.1618] ? btrfs_attach_transaction_barrier+0x23/0x60 [btrfs]<br /> [32.1621] __iterate_supers+0xe8/0x190<br /> [32.1622] ? __pfx_sync_fs_one_sb+0x10/0x10<br /> [32.1623] ksys_sync+0x63/0xb0<br /> [32.1624] __do_sys_sync+0xe/0x20<br /> [32.1625] do_syscall_64+0x73/0x450<br /> [32.1626] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [32.1627] RIP: 0033:0x7f0c28d05d2b<br /> [32.1632] RSP: 002b:00007ffc9d988048 EFLAGS: 00000246 ORIG_RAX:00000000000000a2<br /> [32.1634] RAX: ffffffffffffffda RBX: 00007ffc9d988228 RCX:00007f0c28d05d2b<br /> [32.1636] RDX: 00007f0c28e02301 RSI: 00007ffc9d989b21 RDI:00007f0c28dba90d<br /> [32.1637] RBP: 0000000000000001 R08: 0000000000000001 R09:0000000000000000<br /> [32.1639] R10: 0000000000000000 R11: 0000000000000246 R12:000055b96572cb80<br /> [32.1641] R13: 000055b96572b19f R14: 00007f0c28dfa434 R15:000055b96572b034<br /> [32.1643] <br /> [32.1644] irq event stamp: 0<br /> [32.1644] hardirqs last enabled at (0): [] 0x0<br /> [32.1646] hardirqs last disabled at (0): []copy_process+0xb37/0x2260<br /> [32.1648] softirqs last enabled at (0): []copy_process+0xb37/0x2260<br /> [32.1650] softirqs last disabled at (0): [] 0x0<br /> [32.1652] ---[ end trace 0000000000000000 ]---<br /> <br /> Furthermore, this list corruption eventually (when we happen to add a<br /> new block group) results in getting the switch_commits and<br /> dirty_cowonly_roots lists mixed up and attempting to call update_root<br /> on the tree root which can&amp;#39;t be found in the tree root, resulting in a<br /> transaction abort:<br /> <br /> [87.8269] BTRFS critical (device nvme1n1): unable to find root key (1 0 0) in tree 1<br /> [87.8272] ------------[ cut here ]------------<br /> [87.8274] BTRFS: Transaction aborted (error -117)<br /> [87.8275] WARNING: fs/btrfs/root-tree.c:153 at 0x0, CPU#4: sync/703<br /> [87.8285] CPU: 4 UID: 0 PID: 703 Comm: sync Not tainted 6.18.0 #25 PREEMPT(none)<br /> [87.8287] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-4.fc41 0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: clear stale link mapping of ahvif-&gt;links_map<br /> <br /> When an arvif is initialized in non-AP STA mode but MLO connection<br /> preparation fails before the arvif is created<br /> (arvif-&gt;is_created remains false), the error path attempts to delete all<br /> links. However, link deletion only executes when arvif-&gt;is_created is true.<br /> As a result, ahvif retains a stale entry of arvif that is initialized but<br /> not created.<br /> <br /> When a new arvif is initialized with the same link id, this stale mapping<br /> triggers the following WARN_ON.<br /> <br /> WARNING: drivers/net/wireless/ath/ath12k/mac.c:4271 at ath12k_mac_op_change_vif_links+0x140/0x180 [ath12k], CPU#3: wpa_supplicant/275<br /> <br /> Call trace:<br /> ath12k_mac_op_change_vif_links+0x140/0x180 [ath12k] (P)<br /> drv_change_vif_links+0xbc/0x1a4 [mac80211]<br /> ieee80211_vif_update_links+0x54c/0x6a0 [mac80211]<br /> ieee80211_vif_set_links+0x40/0x70 [mac80211]<br /> ieee80211_prep_connection+0x84/0x450 [mac80211]<br /> ieee80211_mgd_auth+0x200/0x480 [mac80211]<br /> ieee80211_auth+0x14/0x20 [mac80211]<br /> cfg80211_mlme_auth+0x90/0xf0 [cfg80211]<br /> nl80211_authenticate+0x32c/0x380 [cfg80211]<br /> genl_family_rcv_msg_doit+0xc8/0x134<br /> <br /> Fix this issue by unassigning the link vif and clearing ahvif-&gt;links_map<br /> if arvif is only initialized but not created.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1