Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: Prevent potential deadlocks in zone write plug error recovery<br /> <br /> Zone write plugging for handling writes to zones of a zoned block<br /> device always execute a zone report whenever a write BIO to a zone<br /> fails. The intent of this is to ensure that the tracking of a zone write<br /> pointer is always correct to ensure that the alignment to a zone write<br /> pointer of write BIOs can be checked on submission and that we can<br /> always correctly emulate zone append operations using regular write<br /> BIOs.<br /> <br /> However, this error recovery scheme introduces a potential deadlock if a<br /> device queue freeze is initiated while BIOs are still plugged in a zone<br /> write plug and one of these write operation fails. In such case, the<br /> disk zone write plug error recovery work is scheduled and executes a<br /> report zone. This in turn can result in a request allocation in the<br /> underlying driver to issue the report zones command to the device. But<br /> with the device queue freeze already started, this allocation will<br /> block, preventing the report zone execution and the continuation of the<br /> processing of the plugged BIOs. As plugged BIOs hold a queue usage<br /> reference, the queue freeze itself will never complete, resulting in a<br /> deadlock.<br /> <br /> Avoid this problem by completely removing from the zone write plugging<br /> code the use of report zones operations after a failed write operation,<br /> instead relying on the device user to either execute a report zones,<br /> reset the zone, finish the zone, or give up writing to the device (which<br /> is a fairly common pattern for file systems which degrade to read-only<br /> after write failures). This is not an unreasonnable requirement as all<br /> well-behaved applications, FSes and device mapper already use report<br /> zones to recover from write errors whenever possible by comparing the<br /> current position of a zone write pointer with what their assumption<br /> about the position is.<br /> <br /> The changes to remove the automatic error recovery are as follows:<br /> - Completely remove the error recovery work and its associated<br /> resources (zone write plug list head, disk error list, and disk<br /> zone_wplugs_work work struct). This also removes the functions<br /> disk_zone_wplug_set_error() and disk_zone_wplug_clear_error().<br /> <br /> - Change the BLK_ZONE_WPLUG_ERROR zone write plug flag into<br /> BLK_ZONE_WPLUG_NEED_WP_UPDATE. This new flag is set for a zone write<br /> plug whenever a write opration targetting the zone of the zone write<br /> plug fails. This flag indicates that the zone write pointer offset is<br /> not reliable and that it must be updated when the next report zone,<br /> reset zone, finish zone or disk revalidation is executed.<br /> <br /> - Modify blk_zone_write_plug_bio_endio() to set the<br /> BLK_ZONE_WPLUG_NEED_WP_UPDATE flag for the target zone of a failed<br /> write BIO.<br /> <br /> - Modify the function disk_zone_wplug_set_wp_offset() to clear this<br /> new flag, thus implementing recovery of a correct write pointer<br /> offset with the reset (all) zone and finish zone operations.<br /> <br /> - Modify blkdev_report_zones() to always use the disk_report_zones_cb()<br /> callback so that disk_zone_wplug_sync_wp_offset() can be called for<br /> any zone marked with the BLK_ZONE_WPLUG_NEED_WP_UPDATE flag.<br /> This implements recovery of a correct write pointer offset for zone<br /> write plugs marked with BLK_ZONE_WPLUG_NEED_WP_UPDATE and within<br /> the range of the report zones operation executed by the user.<br /> <br /> - Modify blk_revalidate_seq_zone() to call<br /> disk_zone_wplug_sync_wp_offset() for all sequential write required<br /> zones when a zoned block device is revalidated, thus always resolving<br /> any inconsistency between the write pointer offset of zone write<br /> plugs and the actual write pointer position of sequential zones.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Fix IPIs usage in kfence_protect_page()<br /> <br /> flush_tlb_kernel_range() may use IPIs to flush the TLBs of all the<br /> cores, which triggers the following warning when the irqs are disabled:<br /> <br /> [ 3.455330] WARNING: CPU: 1 PID: 0 at kernel/smp.c:815 smp_call_function_many_cond+0x452/0x520<br /> [ 3.456647] Modules linked in:<br /> [ 3.457218] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7-00010-g91d3de7240b8 #1<br /> [ 3.457416] Hardware name: QEMU QEMU Virtual Machine, BIOS<br /> [ 3.457633] epc : smp_call_function_many_cond+0x452/0x520<br /> [ 3.457736] ra : on_each_cpu_cond_mask+0x1e/0x30<br /> [ 3.457786] epc : ffffffff800b669a ra : ffffffff800b67c2 sp : ff2000000000bb50<br /> [ 3.457824] gp : ffffffff815212b8 tp : ff6000008014f080 t0 : 000000000000003f<br /> [ 3.457859] t1 : ffffffff815221e0 t2 : 000000000000000f s0 : ff2000000000bc10<br /> [ 3.457920] s1 : 0000000000000040 a0 : ffffffff815221e0 a1 : 0000000000000001<br /> [ 3.457953] a2 : 0000000000010000 a3 : 0000000000000003 a4 : 0000000000000000<br /> [ 3.458006] a5 : 0000000000000000 a6 : ffffffffffffffff a7 : 0000000000000000<br /> [ 3.458042] s2 : ffffffff815223be s3 : 00fffffffffff000 s4 : ff600001ffe38fc0<br /> [ 3.458076] s5 : ff600001ff950d00 s6 : 0000000200000120 s7 : 0000000000000001<br /> [ 3.458109] s8 : 0000000000000001 s9 : ff60000080841ef0 s10: 0000000000000001<br /> [ 3.458141] s11: ffffffff81524812 t3 : 0000000000000001 t4 : ff60000080092bc0<br /> [ 3.458172] t5 : 0000000000000000 t6 : ff200000000236d0<br /> [ 3.458203] status: 0000000200000100 badaddr: ffffffff800b669a cause: 0000000000000003<br /> [ 3.458373] [] smp_call_function_many_cond+0x452/0x520<br /> [ 3.458593] [] on_each_cpu_cond_mask+0x1e/0x30<br /> [ 3.458625] [] __flush_tlb_range+0x118/0x1ca<br /> [ 3.458656] [] flush_tlb_kernel_range+0x1e/0x26<br /> [ 3.458683] [] kfence_protect+0xc0/0xce<br /> [ 3.458717] [] kfence_guarded_free+0xc6/0x1c0<br /> [ 3.458742] [] __kfence_free+0x62/0xc6<br /> [ 3.458764] [] kfree+0x106/0x32c<br /> [ 3.458786] [] detach_buf_split+0x188/0x1a8<br /> [ 3.458816] [] virtqueue_get_buf_ctx+0xb6/0x1f6<br /> [ 3.458839] [] virtqueue_get_buf+0xe/0x16<br /> [ 3.458880] [] virtblk_done+0x5c/0xe2<br /> [ 3.458908] [] vring_interrupt+0x6a/0x74<br /> [ 3.458930] [] __handle_irq_event_percpu+0x7c/0xe2<br /> [ 3.458956] [] handle_irq_event+0x3c/0x86<br /> [ 3.458978] [] handle_simple_irq+0x9e/0xbe<br /> [ 3.459004] [] generic_handle_domain_irq+0x1c/0x2a<br /> [ 3.459027] [] imsic_handle_irq+0xba/0x120<br /> [ 3.459056] [] generic_handle_domain_irq+0x1c/0x2a<br /> [ 3.459080] [] riscv_intc_aia_irq+0x24/0x34<br /> [ 3.459103] [] handle_riscv_irq+0x2e/0x4c<br /> [ 3.459133] [] call_on_irq_stack+0x32/0x40<br /> <br /> So only flush the local TLB and let the lazy kfence page fault handling<br /> deal with the faults which could happen when a core has an old protected<br /> pte version cached in its TLB. That leads to potential inaccuracies which<br /> can be tolerated when using kfence.

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 /> Bluetooth: iso: Fix circular lock in iso_conn_big_sync<br /> <br /> This fixes the circular locking dependency warning below, by reworking<br /> iso_sock_recvmsg, to ensure that the socket lock is always released<br /> before calling a function that locks hdev.<br /> <br /> [ 561.670344] ======================================================<br /> [ 561.670346] WARNING: possible circular locking dependency detected<br /> [ 561.670349] 6.12.0-rc6+ #26 Not tainted<br /> [ 561.670351] ------------------------------------------------------<br /> [ 561.670353] iso-tester/3289 is trying to acquire lock:<br /> [ 561.670355] ffff88811f600078 (&amp;hdev-&gt;lock){+.+.}-{3:3},<br /> at: iso_conn_big_sync+0x73/0x260 [bluetooth]<br /> [ 561.670405]<br /> but task is already holding lock:<br /> [ 561.670407] ffff88815af58258 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0},<br /> at: iso_sock_recvmsg+0xbf/0x500 [bluetooth]<br /> [ 561.670450]<br /> which lock already depends on the new lock.<br /> <br /> [ 561.670452]<br /> the existing dependency chain (in reverse order) is:<br /> [ 561.670453]<br /> -&gt; #2 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0}:<br /> [ 561.670458] lock_acquire+0x7c/0xc0<br /> [ 561.670463] lock_sock_nested+0x3b/0xf0<br /> [ 561.670467] bt_accept_dequeue+0x1a5/0x4d0 [bluetooth]<br /> [ 561.670510] iso_sock_accept+0x271/0x830 [bluetooth]<br /> [ 561.670547] do_accept+0x3dd/0x610<br /> [ 561.670550] __sys_accept4+0xd8/0x170<br /> [ 561.670553] __x64_sys_accept+0x74/0xc0<br /> [ 561.670556] x64_sys_call+0x17d6/0x25f0<br /> [ 561.670559] do_syscall_64+0x87/0x150<br /> [ 561.670563] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 561.670567]<br /> -&gt; #1 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}:<br /> [ 561.670571] lock_acquire+0x7c/0xc0<br /> [ 561.670574] lock_sock_nested+0x3b/0xf0<br /> [ 561.670577] iso_sock_listen+0x2de/0xf30 [bluetooth]<br /> [ 561.670617] __sys_listen_socket+0xef/0x130<br /> [ 561.670620] __x64_sys_listen+0xe1/0x190<br /> [ 561.670623] x64_sys_call+0x2517/0x25f0<br /> [ 561.670626] do_syscall_64+0x87/0x150<br /> [ 561.670629] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 561.670632]<br /> -&gt; #0 (&amp;hdev-&gt;lock){+.+.}-{3:3}:<br /> [ 561.670636] __lock_acquire+0x32ad/0x6ab0<br /> [ 561.670639] lock_acquire.part.0+0x118/0x360<br /> [ 561.670642] lock_acquire+0x7c/0xc0<br /> [ 561.670644] __mutex_lock+0x18d/0x12f0<br /> [ 561.670647] mutex_lock_nested+0x1b/0x30<br /> [ 561.670651] iso_conn_big_sync+0x73/0x260 [bluetooth]<br /> [ 561.670687] iso_sock_recvmsg+0x3e9/0x500 [bluetooth]<br /> [ 561.670722] sock_recvmsg+0x1d5/0x240<br /> [ 561.670725] sock_read_iter+0x27d/0x470<br /> [ 561.670727] vfs_read+0x9a0/0xd30<br /> [ 561.670731] ksys_read+0x1a8/0x250<br /> [ 561.670733] __x64_sys_read+0x72/0xc0<br /> [ 561.670736] x64_sys_call+0x1b12/0x25f0<br /> [ 561.670738] do_syscall_64+0x87/0x150<br /> [ 561.670741] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 561.670744]<br /> other info that might help us debug this:<br /> <br /> [ 561.670745] Chain exists of:<br /> &amp;hdev-&gt;lock --&gt; sk_lock-AF_BLUETOOTH-BTPROTO_ISO --&gt; sk_lock-AF_BLUETOOTH<br /> <br /> [ 561.670751] Possible unsafe locking scenario:<br /> <br /> [ 561.670753] CPU0 CPU1<br /> [ 561.670754] ---- ----<br /> [ 561.670756] lock(sk_lock-AF_BLUETOOTH);<br /> [ 561.670758] lock(sk_lock<br /> AF_BLUETOOTH-BTPROTO_ISO);<br /> [ 561.670761] lock(sk_lock-AF_BLUETOOTH);<br /> [ 561.670764] lock(&amp;hdev-&gt;lock);<br /> [ 561.670767]<br /> *** DEADLOCK ***

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ivpu: Fix WARN in ivpu_ipc_send_receive_internal()<br /> <br /> Move pm_runtime_set_active() to ivpu_pm_init() so when<br /> ivpu_ipc_send_receive_internal() is executed before ivpu_pm_enable()<br /> it already has correct runtime state, even if last resume was<br /> not successful.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ivpu: Fix general protection fault in ivpu_bo_list()<br /> <br /> Check if ctx is not NULL before accessing its fields.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: prevent use of deleted inode<br /> <br /> syzbot reported a WARNING in nilfs_rmdir. [1]<br /> <br /> Because the inode bitmap is corrupted, an inode with an inode number that<br /> should exist as a ".nilfs" file was reassigned by nilfs_mkdir for "file0",<br /> causing an inode duplication during execution. And this causes an<br /> underflow of i_nlink in rmdir operations.<br /> <br /> The inode is used twice by the same task to unmount and remove directories<br /> ".nilfs" and "file0", it trigger warning in nilfs_rmdir.<br /> <br /> Avoid to this issue, check i_nlink in nilfs_iget(), if it is 0, it means<br /> that this inode has been deleted, and iput is executed to reclaim it.<br /> <br /> [1]<br /> WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407<br /> ...<br /> Call Trace:<br /> <br /> nilfs_rmdir+0x1b0/0x250 fs/nilfs2/namei.c:342<br /> vfs_rmdir+0x3a3/0x510 fs/namei.c:4394<br /> do_rmdir+0x3b5/0x580 fs/namei.c:4453<br /> __do_sys_rmdir fs/namei.c:4472 [inline]<br /> __se_sys_rmdir fs/namei.c:4470 [inline]<br /> __x64_sys_rmdir+0x47/0x50 fs/namei.c:4470<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: axp20x: AXP717: set ramp_delay<br /> <br /> AXP717 datasheet says that regulator ramp delay is 15.625 us/step,<br /> which is 10mV in our case.<br /> <br /> Add a AXP_DESC_RANGES_DELAY macro and update AXP_DESC_RANGES macro to<br /> expand to AXP_DESC_RANGES_DELAY with ramp_delay = 0<br /> <br /> For DCDC4, steps is 100mv<br /> <br /> Add a AXP_DESC_DELAY macro and update AXP_DESC macro to<br /> expand to AXP_DESC_DELAY with ramp_delay = 0<br /> <br /> This patch fix crashes when using CPU DVFS.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: Fix potential invalid memory access in igb_init_module()<br /> <br /> The pci_register_driver() can fail and when this happened, the dca_notifier<br /> needs to be unregistered, otherwise the dca_notifier can be called when<br /> igb fails to install, resulting to invalid memory access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()<br /> <br /> Under certain kernel configurations when building with Clang/LLVM, the<br /> compiler does not generate a return or jump as the terminator<br /> instruction for ip_vs_protocol_init(), triggering the following objtool<br /> warning during build time:<br /> <br /> vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()<br /> <br /> At runtime, this either causes an oops when trying to load the ipvs<br /> module or a boot-time panic if ipvs is built-in. This same issue has<br /> been reported by the Intel kernel test robot previously.<br /> <br /> Digging deeper into both LLVM and the kernel code reveals this to be a<br /> undefined behavior problem. ip_vs_protocol_init() uses a on-stack buffer<br /> of 64 chars to store the registered protocol names and leaves it<br /> uninitialized after definition. The function calls strnlen() when<br /> concatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCE<br /> strnlen() performs an extra step to check whether the last byte of the<br /> input char buffer is a null character (commit 3009f891bb9f ("fortify:<br /> Allow strlen() and strnlen() to pass compile-time known lengths")).<br /> This, together with possibly other configurations, cause the following<br /> IR to be generated:<br /> <br /> define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 {<br /> %1 = alloca [64 x i8], align 16<br /> ...<br /> <br /> 14: ; preds = %11<br /> %15 = getelementptr inbounds i8, ptr %1, i64 63<br /> %16 = load i8, ptr %15, align 1<br /> %17 = tail call i1 @llvm.is.constant.i8(i8 %16)<br /> %18 = icmp eq i8 %16, 0<br /> %19 = select i1 %17, i1 %18, i1 false<br /> br i1 %19, label %20, label %23<br /> <br /> 20: ; preds = %14<br /> %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23<br /> ...<br /> <br /> 23: ; preds = %14, %11, %20<br /> %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24<br /> ...<br /> }<br /> <br /> The above code calculates the address of the last char in the buffer<br /> (value %15) and then loads from it (value %16). Because the buffer is<br /> never initialized, the LLVM GVN pass marks value %16 as undefined:<br /> <br /> %13 = getelementptr inbounds i8, ptr %1, i64 63<br /> br i1 undef, label %14, label %17<br /> <br /> This gives later passes (SCCP, in particular) more DCE opportunities by<br /> propagating the undef value further, and eventually removes everything<br /> after the load on the uninitialized stack location:<br /> <br /> define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 {<br /> %1 = alloca [64 x i8], align 16<br /> ...<br /> <br /> 12: ; preds = %11<br /> %13 = getelementptr inbounds i8, ptr %1, i64 63<br /> unreachable<br /> }<br /> <br /> In this way, the generated native code will just fall through to the<br /> next function, as LLVM does not generate any code for the unreachable IR<br /> instruction and leaves the function without a terminator.<br /> <br /> Zero the on-stack buffer to avoid this possible UB.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: give up on paths longer than PATH_MAX<br /> <br /> If the full path to be built by ceph_mdsc_build_path() happens to be<br /> longer than PATH_MAX, then this function will enter an endless (retry)<br /> loop, effectively blocking the whole task. Most of the machine<br /> becomes unusable, making this a very simple and effective DoS<br /> vulnerability.<br /> <br /> I cannot imagine why this retry was ever implemented, but it seems<br /> rather useless and harmful to me. Let&amp;#39;s remove it and fail with<br /> ENAMETOOLONG instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Fix NEXT_BUDDY<br /> <br /> Adam reports that enabling NEXT_BUDDY insta triggers a WARN in<br /> pick_next_entity().<br /> <br /> Moving clear_buddies() up before the delayed dequeue bits ensures<br /> no -&gt;next buddy becomes delayed. Further ensure no new -&gt;next buddy<br /> ever starts as delayed.