Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> timekeeping: Adjust the leap state for the correct auxiliary timekeeper<br /> <br /> When __do_ajdtimex() was introduced to handle adjtimex for any<br /> timekeeper, this reference to tk_core was not updated. When called on an<br /> auxiliary timekeeper, the core timekeeper would be updated incorrectly.<br /> <br /> This gets caught by the lock debugging diagnostics because the<br /> timekeepers sequence lock gets written to without holding its<br /> associated spinlock:<br /> <br /> WARNING: include/linux/seqlock.h:226 at __do_adjtimex+0x394/0x3b0, CPU#2: test/125<br /> aux_clock_adj (kernel/time/timekeeping.c:2979)<br /> __do_sys_clock_adjtime (kernel/time/posix-timers.c:1161 kernel/time/posix-timers.c:1173)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)<br /> <br /> Update the correct auxiliary timekeeper.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/fpsimd: signal: Allocate SSVE storage when restoring ZA<br /> <br /> The code to restore a ZA context doesn&amp;#39;t attempt to allocate the task&amp;#39;s<br /> sve_state before setting TIF_SME. Consequently, restoring a ZA context<br /> can place a task into an invalid state where TIF_SME is set but the<br /> task&amp;#39;s sve_state is NULL.<br /> <br /> In legitimate but uncommon cases where the ZA signal context was NOT<br /> created by the kernel in the context of the same task (e.g. if the task<br /> is saved/restored with something like CRIU), we have no guarantee that<br /> sve_state had been allocated previously. In these cases, userspace can<br /> enter streaming mode without trapping while sve_state is NULL, causing a<br /> later NULL pointer dereference when the kernel attempts to store the<br /> register state:<br /> <br /> | # ./sigreturn-za<br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> | Mem abort info:<br /> | ESR = 0x0000000096000046<br /> | EC = 0x25: DABT (current EL), IL = 32 bits<br /> | SET = 0, FnV = 0<br /> | EA = 0, S1PTW = 0<br /> | FSC = 0x06: level 2 translation fault<br /> | Data abort info:<br /> | ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000<br /> | CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> | user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00<br /> | [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000<br /> | Internal error: Oops: 0000000096000046 [#1] SMP<br /> | Modules linked in:<br /> | CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> | pc : sve_save_state+0x4/0xf0<br /> | lr : fpsimd_save_user_state+0xb0/0x1c0<br /> | sp : ffff80008070bcc0<br /> | x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658<br /> | x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000<br /> | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40<br /> | x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000<br /> | x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c<br /> | x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020<br /> | x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0<br /> | x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48<br /> | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000<br /> | x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440<br /> | Call trace:<br /> | sve_save_state+0x4/0xf0 (P)<br /> | fpsimd_thread_switch+0x48/0x198<br /> | __switch_to+0x20/0x1c0<br /> | __schedule+0x36c/0xce0<br /> | schedule+0x34/0x11c<br /> | exit_to_user_mode_loop+0x124/0x188<br /> | el0_interrupt+0xc8/0xd8<br /> | __el0_irq_handler_common+0x18/0x24<br /> | el0t_64_irq_handler+0x10/0x1c<br /> | el0t_64_irq+0x198/0x19c<br /> | Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800)<br /> | ---[ end trace 0000000000000000 ]---<br /> <br /> Fix this by having restore_za_context() ensure that the task&amp;#39;s sve_state<br /> is allocated, matching what we do when taking an SME trap. Any live<br /> SVE/SSVE state (which is restored earlier from a separate signal<br /> context) must be preserved, and hence this is not zeroed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak<br /> <br /> Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:<br /> gs_usb_receive_bulk_callback(): fix URB memory leak").<br /> <br /> In usb_8dev_open() -&gt; usb_8dev_start(), the URBs for USB-in transfers are<br /> allocated, added to the priv-&gt;rx_submitted anchor and submitted. In the<br /> complete callback usb_8dev_read_bulk_callback(), the URBs are processed and<br /> resubmitted. In usb_8dev_close() -&gt; unlink_all_urbs() the URBs are freed by<br /> calling usb_kill_anchored_urbs(&amp;priv-&gt;rx_submitted).<br /> <br /> However, this does not take into account that the USB framework unanchors<br /> the URB before the complete function is called. This means that once an<br /> in-URB has been completed, it is no longer anchored and is ultimately not<br /> released in usb_kill_anchored_urbs().<br /> <br /> Fix the memory leak by anchoring the URB in the<br /> usb_8dev_read_bulk_callback() to the priv-&gt;rx_submitted anchor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes()<br /> <br /> Above the while() loop in wait_sb_inodes(), we document that we must wait<br /> for all pages under writeback for data integrity. Consequently, if a<br /> mapping, like fuse, traditionally does not have data integrity semantics,<br /> there is no need to wait at all; we can simply skip these inodes.<br /> <br /> This restores fuse back to prior behavior where syncs are no-ops. This<br /> fixes a user regression where if a system is running a faulty fuse server<br /> that does not reply to issued write requests, this causes wait_sb_inodes()<br /> to wait forever.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Wake up the error handler when final completions race against each other<br /> <br /> The fragile ordering between marking commands completed or failed so<br /> that the error handler only wakes when the last running command<br /> completes or times out has race conditions. These race conditions can<br /> cause the SCSI layer to fail to wake the error handler, leaving I/O<br /> through the SCSI host stuck as the error state cannot advance.<br /> <br /> First, there is an memory ordering issue within scsi_dec_host_busy().<br /> The write which clears SCMD_STATE_INFLIGHT may be reordered with reads<br /> counting in scsi_host_busy(). While the local CPU will see its own<br /> write, reordering can allow other CPUs in scsi_dec_host_busy() or<br /> scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to<br /> see a host busy equal to the host_failed count.<br /> <br /> This race condition can be prevented with a memory barrier on the error<br /> path to force the write to be visible before counting host busy<br /> commands.<br /> <br /> Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By<br /> counting busy commands before incrementing host_failed, it can race with a<br /> final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does<br /> not see host_failed incremented but scsi_eh_inc_host_failed() counts busy<br /> commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),<br /> resulting in neither waking the error handler task.<br /> <br /> This needs the call to scsi_host_busy() to be moved after host_failed is<br /> incremented to close the race condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: dac: ad3552r-hs: fix out-of-bound write in ad3552r_hs_write_data_source<br /> <br /> When simple_write_to_buffer() succeeds, it returns the number of bytes<br /> actually copied to the buffer. The code incorrectly uses &amp;#39;count&amp;#39;<br /> as the index for null termination instead of the actual bytes copied.<br /> If count exceeds the buffer size, this leads to out-of-bounds write.<br /> Add a check for the count and use the return value as the index.<br /> <br /> The bug was validated using a demo module that mirrors the original<br /> code and was tested under QEMU.<br /> <br /> Pattern of the bug:<br /> - A fixed 64-byte stack buffer is filled using count.<br /> - If count &gt; 64, the code still does buf[count] = &amp;#39;\0&amp;#39;, causing an<br /> - out-of-bounds write on the stack.<br /> <br /> Steps for reproduce:<br /> - Opens the device node.<br /> - Writes 128 bytes of A to it.<br /> - This overflows the 64-byte stack buffer and KASAN reports the OOB.<br /> <br /> Found via static analysis. This is similar to the<br /> commit da9374819eb3 ("iio: backend: fix out-of-bound write")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: smbd: fix dma_unmap_sg() nents<br /> <br /> The dma_unmap_sg() functions should be called with the same nents as the<br /> dma_map_sg(), not the value the map function returned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uacce: fix isolate sysfs check condition<br /> <br /> uacce supports the device isolation feature. If the driver<br /> implements the isolate_err_threshold_read and<br /> isolate_err_threshold_write callback functions, uacce will create<br /> sysfs files now. Users can read and configure the isolation policy<br /> through sysfs. Currently, sysfs files are created as long as either<br /> isolate_err_threshold_read or isolate_err_threshold_write callback<br /> functions are present.<br /> <br /> However, accessing a non-existent callback function may cause the<br /> system to crash. Therefore, intercept the creation of sysfs if<br /> neither read nor write exists; create sysfs if either is supported,<br /> but intercept unsupported operations at the call site.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gue: Fix skb memleak with inner IP protocol 0.<br /> <br /> syzbot reported skb memleak below. [0]<br /> <br /> The repro generated a GUE packet with its inner protocol 0.<br /> <br /> gue_udp_recv() returns -guehdr-&gt;proto_ctype for "resubmit"<br /> in ip_protocol_deliver_rcu(), but this only works with<br /> non-zero protocol number.<br /> <br /> Let&amp;#39;s drop such packets.<br /> <br /> Note that 0 is a valid number (IPv6 Hop-by-Hop Option).<br /> <br /> I think it is not practical to encap HOPOPT in GUE, so once<br /> someone starts to complain, we could pass down a resubmit<br /> flag pointer to distinguish two zeros from the upper layer:<br /> <br /> * no error<br /> * resubmit HOPOPT<br /> <br /> [0]<br /> BUG: memory leak<br /> unreferenced object 0xffff888109695a00 (size 240):<br /> comm "syz.0.17", pid 6088, jiffies 4294943096<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@..............<br /> backtrace (crc a84b336f):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4958 [inline]<br /> slab_alloc_node mm/slub.c:5263 [inline]<br /> kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270<br /> __build_skb+0x23/0x60 net/core/skbuff.c:474<br /> build_skb+0x20/0x190 net/core/skbuff.c:490<br /> __tun_build_skb drivers/net/tun.c:1541 [inline]<br /> tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636<br /> tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770<br /> tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x45d/0x710 fs/read_write.c:686<br /> ksys_write+0xa7/0x170 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uacce: fix cdev handling in the cleanup path<br /> <br /> When cdev_device_add fails, it internally releases the cdev memory,<br /> and if cdev_device_del is then executed, it will cause a hang error.<br /> To fix it, we check the return value of cdev_device_add() and clear<br /> uacce-&gt;cdev to avoid calling cdev_device_del in the uacce_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> migrate: correct lock ordering for hugetlb file folios<br /> <br /> Syzbot has found a deadlock (analyzed by Lance Yang):<br /> <br /> 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).<br /> 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire<br /> folio_lock.<br /> <br /> migrate_pages()<br /> -&gt; migrate_hugetlbs()<br /> -&gt; unmap_and_move_huge_page() remove_migration_ptes()<br /> -&gt; __rmap_walk_file()<br /> -&gt; i_mmap_lock_read() hugetlbfs_punch_hole() hugetlbfs_zero_partial_page()<br /> -&gt; filemap_lock_hugetlb_folio()<br /> -&gt; filemap_lock_folio()<br /> -&gt; __filemap_get_folio

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netrom: fix double-free in nr_route_frame()<br /> <br /> In nr_route_frame(), old_skb is immediately freed without checking if<br /> nr_neigh-&gt;ax25 pointer is NULL. Therefore, if nr_neigh-&gt;ax25 is NULL,<br /> the caller function will free old_skb again, causing a double-free bug.<br /> <br /> Therefore, to prevent this, we need to modify it to check whether<br /> nr_neigh-&gt;ax25 is NULL before freeing old_skb.