Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: wpcm-fiu: Fix potential NULL pointer dereference in wpcm_fiu_probe()<br /> <br /> platform_get_resource_byname() can return NULL, which would cause a crash<br /> when passed the pointer to resource_size().<br /> <br /> Move the fiu-&gt;memory_size assignment after the error check for<br /> devm_ioremap_resource() to prevent the potential NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix out-of-bound access in fib6_add_rt2node().<br /> <br /> syzbot reported out-of-bound read in fib6_add_rt2node(). [0]<br /> <br /> When IPv6 route is created with RTA_NH_ID, struct fib6_info<br /> does not have the trailing struct fib6_nh.<br /> <br /> The cited commit started to check !iter-&gt;fib6_nh-&gt;fib_nh_gw_family<br /> to ensure that rt6_qualify_for_ecmp() will return false for iter.<br /> <br /> If iter-&gt;nh is not NULL, rt6_qualify_for_ecmp() returns false anyway.<br /> <br /> Let&amp;#39;s check iter-&gt;nh before reading iter-&gt;fib6_nh and avoid OOB read.<br /> <br /> [0]:<br /> BUG: KASAN: slab-out-of-bounds in fib6_add_rt2node+0x349c/0x3500 net/ipv6/ip6_fib.c:1142<br /> Read of size 1 at addr ffff8880384ba6de by task syz.0.18/5500<br /> <br /> CPU: 0 UID: 0 PID: 5500 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xba/0x230 mm/kasan/report.c:482<br /> kasan_report+0x117/0x150 mm/kasan/report.c:595<br /> fib6_add_rt2node+0x349c/0x3500 net/ipv6/ip6_fib.c:1142<br /> fib6_add_rt2node_nh net/ipv6/ip6_fib.c:1363 [inline]<br /> fib6_add+0x910/0x18c0 net/ipv6/ip6_fib.c:1531<br /> __ip6_ins_rt net/ipv6/route.c:1351 [inline]<br /> ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3957<br /> inet6_rtm_newroute+0x268/0x19e0 net/ipv6/route.c:5660<br /> rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958<br /> netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592<br /> ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646<br /> __sys_sendmsg net/socket.c:2678 [inline]<br /> __do_sys_sendmsg net/socket.c:2683 [inline]<br /> __se_sys_sendmsg net/socket.c:2681 [inline]<br /> __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f9316b9aeb9<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffd8809b678 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f9316e15fa0 RCX: 00007f9316b9aeb9<br /> RDX: 0000000000000000 RSI: 0000200000004380 RDI: 0000000000000003<br /> RBP: 00007f9316c08c1f R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f9316e15fac R14: 00007f9316e15fa0 R15: 00007f9316e15fa0<br /> <br /> <br /> Allocated by task 5499:<br /> kasan_save_stack mm/kasan/common.c:57 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78<br /> poison_kmalloc_redzone mm/kasan/common.c:398 [inline]<br /> __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415<br /> kasan_kmalloc include/linux/kasan.h:263 [inline]<br /> __do_kmalloc_node mm/slub.c:5657 [inline]<br /> __kmalloc_noprof+0x40c/0x7e0 mm/slub.c:5669<br /> kmalloc_noprof include/linux/slab.h:961 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> fib6_info_alloc+0x30/0xf0 net/ipv6/ip6_fib.c:155<br /> ip6_route_info_create+0x142/0x860 net/ipv6/route.c:3820<br /> ip6_route_add+0x49/0x1b0 net/ipv6/route.c:3949<br /> inet6_rtm_newroute+0x268/0x19e0 net/ipv6/route.c:5660<br /> rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958<br /> netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592<br /> ___sys_s<br /> ---truncated---

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.