Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Avoid a NULL pointer dereference<br /> <br /> [WHY]<br /> Although unlikely drm_atomic_get_new_connector_state() or<br /> drm_atomic_get_old_connector_state() can return NULL.<br /> <br /> [HOW]<br /> Check returns before dereference.<br /> <br /> (cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix a race when updating an existing write<br /> <br /> After nfs_lock_and_join_requests() tests for whether the request is<br /> still attached to the mapping, nothing prevents a call to<br /> nfs_inode_remove_request() from succeeding until we actually lock the<br /> page group.<br /> The reason is that whoever called nfs_inode_remove_request() doesn&amp;#39;t<br /> necessarily have a lock on the page group head.<br /> <br /> So in order to avoid races, let&amp;#39;s take the page group lock earlier in<br /> nfs_lock_and_join_requests(), and hold it across the removal of the<br /> request in nfs_inode_remove_request().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/riscv: prevent NULL deref in iova_to_phys<br /> <br /> The riscv_iommu_pte_fetch() function returns either NULL for<br /> unmapped/never-mapped iova, or a valid leaf pte pointer that<br /> requires no further validation.<br /> <br /> riscv_iommu_iova_to_phys() failed to handle NULL returns.<br /> Prevent null pointer dereference in<br /> riscv_iommu_iova_to_phys(), and remove the pte validation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Flush delayed SKBs while releasing RXE resources<br /> <br /> When skb packets are sent out, these skb packets still depends on<br /> the rxe resources, for example, QP, sk, when these packets are<br /> destroyed.<br /> <br /> If these rxe resources are released when the skb packets are destroyed,<br /> the call traces will appear.<br /> <br /> To avoid skb packets hang too long time in some network devices,<br /> a timestamp is added when these skb packets are created. If these<br /> skb packets hang too long time in network devices, these network<br /> devices can free these skb packets to release rxe resources.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: tas2781: Fix wrong reference of tasdevice_priv<br /> <br /> During the conversion to unify the calibration data management, the<br /> reference to tasdevice_priv was wrongly set to h-&gt;hda_priv instead of<br /> h-&gt;priv. This resulted in memory corruption and crashes eventually.<br /> Unfortunately it&amp;#39;s a void pointer, hence the compiler couldn&amp;#39;t know<br /> that it&amp;#39;s wrong.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/futex: ensure io_futex_wait() cleans up properly on failure<br /> <br /> The io_futex_data is allocated upfront and assigned to the io_kiocb<br /> async_data field, but the request isn&amp;#39;t marked with REQ_F_ASYNC_DATA<br /> at that point. Those two should always go together, as the flag tells<br /> io_uring whether the field is valid or not.<br /> <br /> Additionally, on failure cleanup, the futex handler frees the data but<br /> does not clear -&gt;async_data. Clear the data and the flag in the error<br /> path as well.<br /> <br /> Thanks to Trend Micro Zero Day Initiative and particularly ReDress for<br /> reporting this.

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 /> 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 /> 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: 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 /> 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 /> 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().