Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()<br /> <br /> syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernel<br /> buffer is allocated to hold `insn-&gt;n` samples (each of which is an<br /> `unsigned int`). For some instruction types, `insn-&gt;n` samples are<br /> copied back to user-space, unless an error code is being returned. The<br /> problem is that not all the instruction handlers that need to return<br /> data to userspace fill in the whole `insn-&gt;n` samples, so that there is<br /> an information leak. There is a similar syzbot report for<br /> `do_insnlist_ioctl()`, although it does not have a reproducer for it at<br /> the time of writing.<br /> <br /> One culprit is `insn_rw_emulate_bits()` which is used as the handler for<br /> `INSN_READ` or `INSN_WRITE` instructions for subdevices that do not have<br /> a specific handler for that instruction, but do have an `INSN_BITS`<br /> handler. For `INSN_READ` it only fills in at most 1 sample, so if<br /> `insn-&gt;n` is greater than 1, the remaining `insn-&gt;n - 1` samples copied<br /> to userspace will be uninitialized kernel data.<br /> <br /> Another culprit is `vm80xx_ai_insn_read()` in the "vm80xx" driver. It<br /> never returns an error, even if it fails to fill the buffer.<br /> <br /> Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making sure<br /> that uninitialized parts of the allocated buffer are zeroed before<br /> handling each instruction.<br /> <br /> Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fix<br /> replaced the call to `kmalloc_array()` with `kcalloc()`, but it is not<br /> always necessary to clear the whole buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: pcl726: Prevent invalid irq number<br /> <br /> The reproducer passed in an irq number(0x80008000) that was too large,<br /> which triggered the oob.<br /> <br /> Added an interrupt number check to prevent users from passing in an irq<br /> number that was too large.<br /> <br /> If `it-&gt;options[1]` is 31, then `1 options[1]` value to 30 or lower, or using `1U

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Make insn_rw_emulate_bits() do insn-&gt;n samples<br /> <br /> The `insn_rw_emulate_bits()` function is used as a default handler for<br /> `INSN_READ` instructions for subdevices that have a handler for<br /> `INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a default<br /> handler for `INSN_WRITE` instructions for subdevices that have a handler<br /> for `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the<br /> `INSN_READ` or `INSN_WRITE` instruction handling with a constructed<br /> `INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE`<br /> instructions are supposed to be able read or write multiple samples,<br /> indicated by the `insn-&gt;n` value, but `insn_rw_emulate_bits()` currently<br /> only handles a single sample. For `INSN_READ`, the comedi core will<br /> copy `insn-&gt;n` samples back to user-space. (That triggered KASAN<br /> kernel-infoleak errors when `insn-&gt;n` was greater than 1, but that is<br /> being fixed more generally elsewhere in the comedi core.)<br /> <br /> Make `insn_rw_emulate_bits()` either handle `insn-&gt;n` samples, or return<br /> an error, to conform to the general expectation for `INSN_READ` and<br /> `INSN_WRITE` handlers.

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 /> ftrace: Also allocate and copy hash for reading of filter files<br /> <br /> Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds<br /> the pointer to the global tracer hash to its iterator. Unlike the writer<br /> that allocates a copy of the hash, the reader keeps the pointer to the<br /> filter hashes. This is problematic because this pointer is static across<br /> function calls that release the locks that can update the global tracer<br /> hashes. This can cause UAF and similar bugs.<br /> <br /> Allocate and copy the hash for reading the filter files like it is done<br /> for the writers. This not only fixes UAF bugs, but also makes the code a<br /> bit simpler as it doesn&amp;#39;t have to differentiate when to free the<br /> iterator&amp;#39;s hash between writers and readers.

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 /> 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 /> smb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy()<br /> <br /> We can&amp;#39;t call destroy_workqueue(smb_direct_wq); before stop_sessions()!<br /> <br /> Otherwise already existing connections try to use smb_direct_wq as<br /> a NULL pointer.

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()")