Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uprobes: fix kernel info leak via "[uprobes]" vma<br /> <br /> xol_add_vma() maps the uninitialized page allocated by __create_xol_area()<br /> into userspace. On some architectures (x86) this memory is readable even<br /> without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ,<br /> although this doesn&amp;#39;t really matter, debugger can read this memory anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/timerlat: Drop interface_lock in stop_kthread()<br /> <br /> stop_kthread() is the offline callback for "trace/osnoise:online", since<br /> commit 5bfbcd1ee57b ("tracing/timerlat: Add interface_lock around clearing<br /> of kthread in stop_kthread()"), the following ABBA deadlock scenario is<br /> introduced:<br /> <br /> T1 | T2 [BP] | T3 [AP]<br /> osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun()<br /> | _cpu_down() | osnoise_cpu_die()<br /> mutex_lock(&amp;interface_lock) | | stop_kthread()<br /> | cpus_write_lock() | mutex_lock(&amp;interface_lock)<br /> cpus_read_lock() | cpuhp_kick_ap() |<br /> <br /> As the interface_lock here in just for protecting the "kthread" field of<br /> the osn_var, use xchg() instead to fix this issue. Also use<br /> for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take<br /> cpu_read_lock() again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: Fix zero-division error when disabling tc cbs<br /> <br /> The commit b8c43360f6e4 ("net: stmmac: No need to calculate speed divider<br /> when offload is disabled") allows the "port_transmit_rate_kbps" to be<br /> set to a value of 0, which is then passed to the "div_s64" function when<br /> tc-cbs is disabled. This leads to a zero-division error.<br /> <br /> When tc-cbs is disabled, the idleslope, sendslope, and credit values the<br /> credit values are not required to be configured. Therefore, adding a return<br /> statement after setting the txQ mode to DCB when tc-cbs is disabled would<br /> prevent a zero-division error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gso: fix udp gso fraglist segmentation after pull from frag_list<br /> <br /> Detect gso fraglist skbs with corrupted geometry (see below) and<br /> pass these to skb_segment instead of skb_segment_list, as the first<br /> can segment them correctly.<br /> <br /> Valid SKB_GSO_FRAGLIST skbs<br /> - consist of two or more segments<br /> - the head_skb holds the protocol headers plus first gso_size<br /> - one or more frag_list skbs hold exactly one segment<br /> - all but the last must be gso_size<br /> <br /> Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can<br /> modify these skbs, breaking these invariants.<br /> <br /> In extreme cases they pull all data into skb linear. For UDP, this<br /> causes a NULL ptr deref in __udpv4_gso_segment_list_csum at<br /> udp_hdr(seg-&gt;next)-&gt;dest.<br /> <br /> Detect invalid geometry due to pull, by checking head_skb size.<br /> Don&amp;#39;t just drop, as this may blackhole a destination. Convert to be<br /> able to pass to regular skb_segment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gso: fix tcp fraglist segmentation after pull from frag_list<br /> <br /> Detect tcp gso fraglist skbs with corrupted geometry (see below) and<br /> pass these to skb_segment instead of skb_segment_list, as the first<br /> can segment them correctly.<br /> <br /> Valid SKB_GSO_FRAGLIST skbs<br /> - consist of two or more segments<br /> - the head_skb holds the protocol headers plus first gso_size<br /> - one or more frag_list skbs hold exactly one segment<br /> - all but the last must be gso_size<br /> <br /> Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can<br /> modify these skbs, breaking these invariants.<br /> <br /> In extreme cases they pull all data into skb linear. For TCP, this<br /> causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at<br /> tcp_hdr(seg-&gt;next).<br /> <br /> Detect invalid geometry due to pull, by checking head_skb size.<br /> Don&amp;#39;t just drop, as this may blackhole a destination. Convert to be<br /> able to pass to regular skb_segment.<br /> <br /> Approach and description based on a patch by Willem de Bruijn.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vrf: revert "vrf: Remove unnecessary RCU-bh critical section"<br /> <br /> This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.<br /> <br /> dev_queue_xmit_nit is expected to be called with BH disabled.<br /> __dev_queue_xmit has the following:<br /> <br /> /* Disable soft irqs for various locks below. Also<br /> * stops preemption for RCU.<br /> */<br /> rcu_read_lock_bh();<br /> <br /> VRF must follow this invariant. The referenced commit removed this<br /> protection. Which triggered a lockdep warning:<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 6.11.0 #1 Tainted: G W<br /> --------------------------------<br /> inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage.<br /> btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes:<br /> ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30<br /> {IN-SOFTIRQ-W} state was registered at:<br /> lock_acquire+0x19a/0x4f0<br /> _raw_spin_lock+0x27/0x40<br /> packet_rcv+0xa33/0x1320<br /> __netif_receive_skb_core.constprop.0+0xcb0/0x3a90<br /> __netif_receive_skb_list_core+0x2c9/0x890<br /> netif_receive_skb_list_internal+0x610/0xcc0<br /> [...]<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(rlock-AF_PACKET);<br /> <br /> lock(rlock-AF_PACKET);<br /> <br /> *** DEADLOCK ***<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x73/0xa0<br /> mark_lock+0x102e/0x16b0<br /> __lock_acquire+0x9ae/0x6170<br /> lock_acquire+0x19a/0x4f0<br /> _raw_spin_lock+0x27/0x40<br /> tpacket_rcv+0x863/0x3b30<br /> dev_queue_xmit_nit+0x709/0xa40<br /> vrf_finish_direct+0x26e/0x340 [vrf]<br /> vrf_l3_out+0x5f4/0xe80 [vrf]<br /> __ip_local_out+0x51e/0x7a0<br /> [...]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: fix use after free bug in venus_remove due to race condition<br /> <br /> in venus_probe, core-&gt;work is bound with venus_sys_error_handler, which is<br /> used to handle error. The code use core-&gt;sys_err_done to make sync work.<br /> The core-&gt;work is started in venus_event_notify.<br /> <br /> If we call venus_remove, there might be an unfished work. The possible<br /> sequence is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> |venus_sys_error_handler<br /> venus_remove |<br /> hfi_destroy |<br /> venus_hfi_destroy |<br /> kfree(hdev); |<br /> |hfi_reinit<br /> |venus_hfi_queues_reinit<br /> |//use hdev<br /> <br /> Fix it by canceling the work in venus_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> aoe: fix the potential use-after-free problem in more places<br /> <br /> For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential<br /> use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put()<br /> instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs<br /> into use-after-free.<br /> <br /> Then Nicolai Stange found more places in aoe have potential use-after-free<br /> problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe()<br /> and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push<br /> packet to tx queue. So they should also use dev_hold() to increase the<br /> refcnt of skb-&gt;dev.<br /> <br /> On the other hand, moving dev_put() to tx() causes that the refcnt of<br /> skb-&gt;dev be reduced to a negative value, because corresponding<br /> dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(),<br /> probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: reserve space for inline xattr before attaching reflink tree<br /> <br /> One of our customers reported a crash and a corrupted ocfs2 filesystem. <br /> The crash was due to the detection of corruption. Upon troubleshooting,<br /> the fsck -fn output showed the below corruption<br /> <br /> [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,<br /> but fsck believes the largest valid value is 227. Clamp the next record value? n<br /> <br /> The stat output from the debugfs.ocfs2 showed the following corruption<br /> where the "Next Free Rec:" had overshot the "Count:" in the root metadata<br /> block.<br /> <br /> Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856)<br /> FS Generation: 904309833 (0x35e6ac49)<br /> CRC32: 00000000 ECC: 0000<br /> Type: Regular Attr: 0x0 Flags: Valid<br /> Dynamic Features: (0x16) HasXattr InlineXattr Refcounted<br /> Extended Attributes Block: 0 Extended Attributes Inline Size: 256<br /> User: 0 (root) Group: 0 (root) Size: 281320357888<br /> Links: 1 Clusters: 141738<br /> ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024<br /> atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024<br /> mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024<br /> dtime: 0x0 -- Wed Dec 31 17:00:00 1969<br /> Refcount Block: 2777346<br /> Last Extblk: 2886943 Orphan Slot: 0<br /> Sub Alloc Slot: 0 Sub Alloc Bit: 14<br /> Tree Depth: 1 Count: 227 Next Free Rec: 230<br /> ## Offset Clusters Block#<br /> 0 0 2310 2776351<br /> 1 2310 2139 2777375<br /> 2 4449 1221 2778399<br /> 3 5670 731 2779423<br /> 4 6401 566 2780447<br /> ....... .... .......<br /> ....... .... .......<br /> <br /> The issue was in the reflink workfow while reserving space for inline<br /> xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the<br /> time this function is called the reflink tree is already recreated at the<br /> destination inode from the source inode. At this point, this function<br /> reserves space for inline xattrs at the destination inode without even<br /> checking if there is space at the root metadata block. It simply reduces<br /> the l_count from 243 to 227 thereby making space of 256 bytes for inline<br /> xattr whereas the inode already has extents beyond this index (in this<br /> case up to 230), thereby causing corruption.<br /> <br /> The fix for this is to reserve space for inline metadata at the destination<br /> inode before the reflink tree gets recreated. The customer has verified the<br /> fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error<br /> <br /> In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()<br /> to recover some journal space. But if an error occurs while executing<br /> jbd2_cleanup_journal_tail() (e.g., an EIO), we don&amp;#39;t stop waiting for free<br /> space right away, we try other branches, and if j_committing_transaction<br /> is NULL (i.e., the tid is 0), we will get the following complain:<br /> <br /> ============================================<br /> JBD2: I/O error when updating journal superblock for sdd-8.<br /> __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available<br /> __jbd2_log_wait_for_space: no way to get more journal space in sdd-8<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0<br /> Modules linked in:<br /> CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1<br /> RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0<br /> Call Trace:<br /> <br /> add_transaction_credits+0x5d1/0x5e0<br /> start_this_handle+0x1ef/0x6a0<br /> jbd2__journal_start+0x18b/0x340<br /> ext4_dirty_inode+0x5d/0xb0<br /> __mark_inode_dirty+0xe4/0x5d0<br /> generic_update_time+0x60/0x70<br /> [...]<br /> ============================================<br /> <br /> So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to<br /> clean up at the moment, continue to try to reclaim free space in other ways.<br /> <br /> Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt<br /> when updating journal superblock fails") to make jbd2_cleanup_journal_tail<br /> return the correct error code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix timer use-after-free on failed mount<br /> <br /> Syzbot has found an ODEBUG bug in ext4_fill_super<br /> <br /> The del_timer_sync function cancels the s_err_report timer,<br /> which reminds about filesystem errors daily. We should<br /> guarantee the timer is no longer active before kfree(sbi).<br /> <br /> When filesystem mounting fails, the flow goes to failed_mount3,<br /> where an error occurs when ext4_stop_mmpd is called, causing<br /> a read I/O failure. This triggers the ext4_handle_error function<br /> that ultimately re-arms the timer,<br /> leaving the s_err_report timer active before kfree(sbi) is called.<br /> <br /> Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: ar0521: Use cansleep version of gpiod_set_value()<br /> <br /> If we use GPIO reset from I2C port expander, we must use *_cansleep()<br /> variant of GPIO functions.<br /> This was not done in ar0521_power_on()/ar0521_power_off() functions.<br /> Let&amp;#39;s fix that.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c<br /> Modules linked in:<br /> CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53<br /> Hardware name: Diasom DS-RK3568-SOM-EVB (DT)<br /> Workqueue: events_unbound deferred_probe_work_func<br /> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : gpiod_set_value+0x74/0x7c<br /> lr : ar0521_power_on+0xcc/0x290<br /> sp : ffffff8001d7ab70<br /> x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000<br /> x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088<br /> x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088<br /> x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80<br /> x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000<br /> x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930<br /> x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0<br /> x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780<br /> x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001<br /> Call trace:<br /> gpiod_set_value+0x74/0x7c<br /> ar0521_power_on+0xcc/0x290<br /> ...