Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/buffer: fix use-after-free when call bh_read() helper<br /> <br /> There&amp;#39;s issue as follows:<br /> BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110<br /> Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0<br /> CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x55/0x70<br /> print_address_description.constprop.0+0x2c/0x390<br /> print_report+0xb4/0x270<br /> kasan_report+0xb8/0xf0<br /> end_buffer_read_sync+0xe3/0x110<br /> end_bio_bh_io_sync+0x56/0x80<br /> blk_update_request+0x30a/0x720<br /> scsi_end_request+0x51/0x2b0<br /> scsi_io_completion+0xe3/0x480<br /> ? scsi_device_unbusy+0x11e/0x160<br /> blk_complete_reqs+0x7b/0x90<br /> handle_softirqs+0xef/0x370<br /> irq_exit_rcu+0xa5/0xd0<br /> sysvec_apic_timer_interrupt+0x6e/0x90<br /> <br /> <br /> Above issue happens when do ntfs3 filesystem mount, issue may happens<br /> as follows:<br /> mount IRQ<br /> ntfs_fill_super<br /> read_cache_page<br /> do_read_cache_folio<br /> filemap_read_folio<br /> mpage_read_folio<br /> do_mpage_readpage<br /> ntfs_get_block_vbo<br /> bh_read<br /> submit_bh<br /> wait_on_buffer(bh);<br /> blk_complete_reqs<br /> scsi_io_completion<br /> scsi_end_request<br /> blk_update_request<br /> end_bio_bh_io_sync<br /> end_buffer_read_sync<br /> __end_buffer_read_notouch<br /> unlock_buffer<br /> <br /> wait_on_buffer(bh);--&gt; return will return to caller<br /> <br /> put_bh<br /> --&gt; trigger stack-out-of-bounds<br /> In the mpage_read_folio() function, the stack variable &amp;#39;map_bh&amp;#39; is<br /> passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and<br /> wait_on_buffer() returns to continue processing, the stack variable<br /> is likely to be reclaimed. Consequently, during the end_buffer_read_sync()<br /> process, calling put_bh() may result in stack overrun.<br /> <br /> If the bh is not allocated on the stack, it belongs to a folio. Freeing<br /> a buffer head which belongs to a folio is done by drop_buffers() which<br /> will fail to free buffers which are still locked. So it is safe to call<br /> put_bh() before __end_buffer_read_notouch().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: accel: sca3300: fix uninitialized iio scan data<br /> <br /> Fix potential leak of uninitialized stack data to userspace by ensuring<br /> that the `channels` array is zeroed before use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: as73211: Ensure buffer holes are zeroed<br /> <br /> Given that the buffer is copied to a kfifo that ultimately user space<br /> can read, ensure we zero it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Limit access to parser-&gt;buffer when trace_get_user failed<br /> <br /> When the length of the string written to set_ftrace_filter exceeds<br /> FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:<br /> <br /> BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0<br /> Read of size 1 at addr ffff0000d00bd5ba by task ash/165<br /> <br /> CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> show_stack+0x34/0x50 (C)<br /> dump_stack_lvl+0xa0/0x158<br /> print_address_description.constprop.0+0x88/0x398<br /> print_report+0xb0/0x280<br /> kasan_report+0xa4/0xf0<br /> __asan_report_load1_noabort+0x20/0x30<br /> strsep+0x18c/0x1b0<br /> ftrace_process_regex.isra.0+0x100/0x2d8<br /> ftrace_regex_release+0x484/0x618<br /> __fput+0x364/0xa58<br /> ____fput+0x28/0x40<br /> task_work_run+0x154/0x278<br /> do_notify_resume+0x1f0/0x220<br /> el0_svc+0xec/0xf0<br /> el0t_64_sync_handler+0xa0/0xe8<br /> el0t_64_sync+0x1ac/0x1b0<br /> <br /> The reason is that trace_get_user will fail when processing a string<br /> longer than FTRACE_BUFF_MAX, but not set the end of parser-&gt;buffer to 0.<br /> Then an OOB access will be triggered in ftrace_regex_release-&gt;<br /> ftrace_process_regex-&gt;strsep-&gt;strpbrk. We can solve this problem by<br /> limiting access to parser-&gt;buffer when trace_get_user failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper<br /> <br /> Since<br /> <br /> 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")<br /> <br /> resctrl_cpu_detect() has been moved from common CPU initialization code to<br /> the vendor-specific BSP init helper, while Hygon didn&amp;#39;t put that call in their<br /> code.<br /> <br /> This triggers a division by zero fault during early booting stage on our<br /> machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries<br /> to calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale.<br /> <br /> Add the missing resctrl_cpu_detect() in the Hygon BSP init helper.<br /> <br /> [ bp: Massage commit message. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Fix backlog accounting in qdisc_dequeue_internal<br /> <br /> This issue applies for the following qdiscs: hhf, fq, fq_codel, and<br /> fq_pie, and occurs in their change handlers when adjusting to the new<br /> limit. The problem is the following in the values passed to the<br /> subsequent qdisc_tree_reduce_backlog call given a tbf parent:<br /> <br /> When the tbf parent runs out of tokens, skbs of these qdiscs will<br /> be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued,<br /> which accounts for both qlen and backlog. However, in the case of<br /> qdisc_dequeue_internal, ONLY qlen is accounted for when pulling<br /> from gso_skb. This means that these qdiscs are missing a<br /> qdisc_qstats_backlog_dec when dropping packets to satisfy the<br /> new limit in their change handlers.<br /> <br /> One can observe this issue with the following (with tc patched to<br /> support a limit of 0):<br /> <br /> export TARGET=fq<br /> tc qdisc del dev lo root<br /> tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms<br /> tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000<br /> echo &amp;#39;&amp;#39;; echo &amp;#39;add child&amp;#39;; tc -s -d qdisc show dev lo<br /> ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2&gt;&amp;1 &gt;/dev/null<br /> echo &amp;#39;&amp;#39;; echo &amp;#39;after ping&amp;#39;; tc -s -d qdisc show dev lo<br /> tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0<br /> echo &amp;#39;&amp;#39;; echo &amp;#39;after limit drop&amp;#39;; tc -s -d qdisc show dev lo<br /> tc qdisc replace dev lo handle 2: parent 1:1 sfq<br /> echo &amp;#39;&amp;#39;; echo &amp;#39;post graft&amp;#39;; tc -s -d qdisc show dev lo<br /> <br /> The second to last show command shows 0 packets but a positive<br /> number (74) of backlog bytes. The problem becomes clearer in the<br /> last show command, where qdisc_purge_queue triggers<br /> qdisc_tree_reduce_backlog with the positive backlog and causes an<br /> underflow in the tbf parent&amp;#39;s backlog (4096 Mb instead of 0).<br /> <br /> To fix this issue, the codepath for all clients of qdisc_dequeue_internal<br /> has been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.<br /> qdisc_dequeue_internal handles the backlog adjustments for all cases that<br /> do not directly use the dequeue handler.<br /> <br /> The old fq_codel_change limit adjustment loop accumulated the arguments to<br /> the subsequent qdisc_tree_reduce_backlog call through the cstats field.<br /> However, this is confusing and error prone as fq_codel_dequeue could also<br /> potentially mutate this field (which qdisc_dequeue_internal calls in the<br /> non gso_skb case), so we have unified the code here with other qdiscs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd/hsmp: Ensure sock-&gt;metric_tbl_addr is non-NULL<br /> <br /> If metric table address is not allocated, accessing metrics_bin will<br /> result in a NULL pointer dereference, so add a check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().<br /> <br /> When the nvif_vmm_type is invalid, we will return error directly<br /> without freeing the args in nvif_vmm_ctor(), which leading a memory<br /> leak. Fix it by setting the ret -EINVAL and goto done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xfer<br /> <br /> The data-&gt;block[0] variable comes from user. Without proper check,<br /> the variable may be very large to cause an out-of-bounds bug.<br /> <br /> Fix this bug by checking the value of data-&gt;block[0] first.<br /> <br /> 1. commit 39244cc75482 ("i2c: ismt: Fix an out-of-bounds bug in<br /> ismt_access()")<br /> 2. commit 92fbb6d1296f ("i2c: xgene-slimpro: Fix out-of-bounds bug in<br /> xgene_slimpro_i2c_xfer()")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: fix handling of zero-length records on the rx_list<br /> <br /> Each recvmsg() call must process either<br /> - only contiguous DATA records (any number of them)<br /> - one non-DATA record<br /> <br /> If the next record has different type than what has already been<br /> processed we break out of the main processing loop. If the record<br /> has already been decrypted (which may be the case for TLS 1.3 where<br /> we don&amp;#39;t know type until decryption) we queue the pending record<br /> to the rx_list. Next recvmsg() will pick it up from there.<br /> <br /> Queuing the skb to rx_list after zero-copy decrypt is not possible,<br /> since in that case we decrypted directly to the user space buffer,<br /> and we don&amp;#39;t have an skb to queue (darg.skb points to the ciphertext<br /> skb for access to metadata like length).<br /> <br /> Only data records are allowed zero-copy, and we break the processing<br /> loop after each non-data record. So we should never zero-copy and<br /> then find out that the record type has changed. The corner case<br /> we missed is when the initial record comes from rx_list, and it&amp;#39;s<br /> zero length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: fix race conditions in ppp_fill_forward_path<br /> <br /> ppp_fill_forward_path() has two race conditions:<br /> <br /> 1. The ppp-&gt;channels list can change between list_empty() and<br /> list_first_entry(), as ppp_lock() is not held. If the only channel<br /> is deleted in ppp_disconnect_channel(), list_first_entry() may<br /> access an empty head or a freed entry, and trigger a panic.<br /> <br /> 2. pch-&gt;chan can be NULL. When ppp_unregister_channel() is called,<br /> pch-&gt;chan is set to NULL before pch is removed from ppp-&gt;channels.<br /> <br /> Fix these by using a lockless RCU approach:<br /> - Use list_first_or_null_rcu() to safely test and access the first list<br /> entry.<br /> - Convert list modifications on ppp-&gt;channels to their RCU variants and<br /> add synchronize_net() after removal.<br /> - Check for a NULL pch-&gt;chan before dereferencing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla4xxx: Prevent a potential error pointer dereference<br /> <br /> The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,<br /> but qla4xxx_ep_connect() returns error pointers. Propagating the error<br /> pointers will lead to an Oops in the caller, so change the error pointers<br /> to NULL.