Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work<br /> <br /> The workqueue might still be running, when the driver is stopped. To<br /> avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: fix RCU usage in connect path<br /> <br /> With lockdep enabled, calls to the connect function from cfg802.11 layer<br /> lead to the following warning:<br /> <br /> =============================<br /> WARNING: suspicious RCU usage<br /> 6.7.0-rc1-wt+ #333 Not tainted<br /> -----------------------------<br /> drivers/net/wireless/microchip/wilc1000/hif.c:386<br /> suspicious rcu_dereference_check() usage!<br /> [...]<br /> stack backtrace:<br /> CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333<br /> Hardware name: Atmel SAMA5<br /> unwind_backtrace from show_stack+0x18/0x1c<br /> show_stack from dump_stack_lvl+0x34/0x48<br /> dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4<br /> wilc_parse_join_bss_param from connect+0x2c4/0x648<br /> connect from cfg80211_connect+0x30c/0xb74<br /> cfg80211_connect from nl80211_connect+0x860/0xa94<br /> nl80211_connect from genl_rcv_msg+0x3fc/0x59c<br /> genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8<br /> netlink_rcv_skb from genl_rcv+0x2c/0x3c<br /> genl_rcv from netlink_unicast+0x3b0/0x550<br /> netlink_unicast from netlink_sendmsg+0x368/0x688<br /> netlink_sendmsg from ____sys_sendmsg+0x190/0x430<br /> ____sys_sendmsg from ___sys_sendmsg+0x110/0x158<br /> ___sys_sendmsg from sys_sendmsg+0xe8/0x150<br /> sys_sendmsg from ret_fast_syscall+0x0/0x1c<br /> <br /> This warning is emitted because in the connect path, when trying to parse<br /> target BSS parameters, we dereference a RCU pointer whithout being in RCU<br /> critical section.<br /> Fix RCU dereference usage by moving it to a RCU read critical section. To<br /> avoid wrapping the whole wilc_parse_join_bss_param under the critical<br /> section, just use the critical section to copy ies data

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command<br /> <br /> The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values<br /> in the ATA ID information to calculate cylinder and head values when<br /> creating a CDB for READ or WRITE commands. The calculation involves<br /> division and modulus operations, which will cause a crash if either of<br /> these values is 0. While this never happens with a genuine device, it<br /> could happen with a flawed or subversive emulation, as reported by the<br /> syzbot fuzzer.<br /> <br /> Protect against this possibility by refusing to bind to the device if<br /> either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device&amp;#39;s ID<br /> information is 0. This requires isd200_Initialization() to return a<br /> negative error code when initialization fails; currently it always<br /> returns 0 (even when there is an error).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: do not compare internal table flags on updates<br /> <br /> Restore skipping transaction if table update does not modify flags.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-mt65xx: Fix NULL pointer access in interrupt handler<br /> <br /> The TX buffer in spi_transfer can be a NULL pointer, so the interrupt<br /> handler may end up writing to the invalid memory and cause crashes.<br /> <br /> Add a check to trans-&gt;tx_buf before using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix mmhub client id out-of-bounds access<br /> <br /> Properly handle cid 0x140.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: Use separate handlers for interrupts<br /> <br /> For PF to AF interrupt vector and VF to AF vector same<br /> interrupt handler is registered which is causing race condition.<br /> When two interrupts are raised to two CPUs at same time<br /> then two cores serve same event corrupting the data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix nfs_netfs_issue_read() xarray locking for writeback interrupt<br /> <br /> The loop inside nfs_netfs_issue_read() currently does not disable<br /> interrupts while iterating through pages in the xarray to submit<br /> for NFS read. This is not safe though since after taking xa_lock,<br /> another page in the mapping could be processed for writeback inside<br /> an interrupt, and deadlock can occur. The fix is simple and clean<br /> if we use xa_for_each_range(), which handles the iteration with RCU<br /> while reducing code complexity.<br /> <br /> The problem is easily reproduced with the following test:<br /> mount -o vers=3,fsc 127.0.0.1:/export /mnt/nfs<br /> dd if=/dev/zero of=/mnt/nfs/file1.bin bs=4096 count=1<br /> echo 3 &gt; /proc/sys/vm/drop_caches<br /> dd if=/mnt/nfs/file1.bin of=/dev/null<br /> umount /mnt/nfs<br /> <br /> On the console with a lockdep-enabled kernel a message similar to<br /> the following will be seen:<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 6.7.0-lockdbg+ #10 Not tainted<br /> --------------------------------<br /> inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage.<br /> test5/1708 [HC0[0]:SC0[0]:HE1:SE1] takes:<br /> ffff888127baa598 (&amp;xa-&gt;xa_lock#4){+.?.}-{3:3}, at:<br /> nfs_netfs_issue_read+0x1b2/0x4b0 [nfs]<br /> {IN-SOFTIRQ-W} state was registered at:<br /> lock_acquire+0x144/0x380<br /> _raw_spin_lock_irqsave+0x4e/0xa0<br /> __folio_end_writeback+0x17e/0x5c0<br /> folio_end_writeback+0x93/0x1b0<br /> iomap_finish_ioend+0xeb/0x6a0<br /> blk_update_request+0x204/0x7f0<br /> blk_mq_end_request+0x30/0x1c0<br /> blk_complete_reqs+0x7e/0xa0<br /> __do_softirq+0x113/0x544<br /> __irq_exit_rcu+0xfe/0x120<br /> irq_exit_rcu+0xe/0x20<br /> sysvec_call_function_single+0x6f/0x90<br /> asm_sysvec_call_function_single+0x1a/0x20<br /> pv_native_safe_halt+0xf/0x20<br /> default_idle+0x9/0x20<br /> default_idle_call+0x67/0xa0<br /> do_idle+0x2b5/0x300<br /> cpu_startup_entry+0x34/0x40<br /> start_secondary+0x19d/0x1c0<br /> secondary_startup_64_no_verify+0x18f/0x19b<br /> irq event stamp: 176891<br /> hardirqs last enabled at (176891): []<br /> _raw_spin_unlock_irqrestore+0x44/0x60<br /> hardirqs last disabled at (176890): []<br /> _raw_spin_lock_irqsave+0x79/0xa0<br /> softirqs last enabled at (176646): []<br /> __irq_exit_rcu+0xfe/0x120<br /> softirqs last disabled at (176633): []<br /> __irq_exit_rcu+0xfe/0x120<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;xa-&gt;xa_lock#4);<br /> <br /> lock(&amp;xa-&gt;xa_lock#4);<br /> <br /> *** DEADLOCK ***<br /> <br /> 2 locks held by test5/1708:<br /> #0: ffff888127baa498 (&amp;sb-&gt;s_type-&gt;i_mutex_key#22){++++}-{4:4}, at:<br /> nfs_start_io_read+0x28/0x90 [nfs]<br /> #1: ffff888127baa650 (mapping.invalidate_lock#3){.+.+}-{4:4}, at:<br /> page_cache_ra_unbounded+0xa4/0x280<br /> <br /> stack backtrace:<br /> CPU: 6 PID: 1708 Comm: test5 Kdump: loaded Not tainted 6.7.0-lockdbg+<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39<br /> 04/01/2014<br /> Call Trace:<br /> dump_stack_lvl+0x5b/0x90<br /> mark_lock+0xb3f/0xd20<br /> __lock_acquire+0x77b/0x3360<br /> _raw_spin_lock+0x34/0x80<br /> nfs_netfs_issue_read+0x1b2/0x4b0 [nfs]<br /> netfs_begin_read+0x77f/0x980 [netfs]<br /> nfs_netfs_readahead+0x45/0x60 [nfs]<br /> nfs_readahead+0x323/0x5a0 [nfs]<br /> read_pages+0xf3/0x5c0<br /> page_cache_ra_unbounded+0x1c8/0x280<br /> filemap_get_pages+0x38c/0xae0<br /> filemap_read+0x206/0x5e0<br /> nfs_file_read+0xb7/0x140 [nfs]<br /> vfs_read+0x2a9/0x460<br /> ksys_read+0xb7/0x140

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid potential panic during recovery<br /> <br /> During recovery, if FAULT_BLOCK is on, it is possible that<br /> f2fs_reserve_new_block() will return -ENOSPC during recovery,<br /> then it may trigger panic.<br /> <br /> Also, if fault injection rate is 1 and only FAULT_BLOCK fault<br /> type is on, it may encounter deadloop in loop of block reservation.<br /> <br /> Let&amp;#39;s change as below to fix these issues:<br /> - remove bug_on() to avoid panic.<br /> - limit the loop count of block reservation to avoid potential<br /> deadloop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to remove unnecessary f2fs_bug_on() to avoid panic<br /> <br /> verify_blkaddr() will trigger panic once we inject fault into<br /> f2fs_is_valid_blkaddr(), fix to remove this unnecessary f2fs_bug_on().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: compress: fix to cover normal cluster write with cp_rwsem<br /> <br /> When we overwrite compressed cluster w/ normal cluster, we should<br /> not unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data<br /> will be corrupted if partial blocks were persisted before CP &amp; SPOR,<br /> due to cluster metadata wasn&amp;#39;t updated atomically.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: compress: fix to guarantee persisting compressed blocks by CP<br /> <br /> If data block in compressed cluster is not persisted with metadata<br /> during checkpoint, after SPOR, the data may be corrupted, let&amp;#39;s<br /> guarantee to write compressed page by checkpoint.