Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exec: fix unsigned loop counter wrap in transfer_args_to_stack()<br /> <br /> The stop value is derived from bprm-&gt;p &gt;&gt; PAGE_SHIFT. The index variable<br /> is an unsigned long. If bprm-&gt;p drops below PAGE_SIZE and stop becomes<br /> zero the loop condition index &gt;= stop is always true.<br /> <br /> After the index == 0 iteration the decrement wraps to ULONG_MAX and<br /> bprm-&gt;page[ULONG_MAX] reads sizeof(void *) bytes in front of the array.<br /> The pointer has wrapped to -1. That garbage pointer is then passed to<br /> kmap_local_page() and PAGE_SIZE bytes are copied from wherever that<br /> lands into the stack of the process being created. And the loop doesn&amp;#39;t<br /> terminate either...<br /> <br /> Getting there only requires bprm-&gt;p p is pushed down is valid_arg_len(), i.e.<br /> that each individual string still fits in what is left.<br /> <br /> bprm-&gt;p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a<br /> single argument or environment string of a little over 31 pages leaves<br /> it in the first page:<br /> <br /> Oops - load access fault [#1]<br /> CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1<br /> epc : __memcpy+0xd4/0xf8<br /> ra : transfer_args_to_stack+0xaa/0xae<br /> s4 : ffffffffffffffff s2 : 0000000000000000<br /> a1 : ffffffdc98000000 a2 : 0000000000001000<br /> status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005<br /> [] __memcpy+0xd4/0xf8<br /> [] load_flat_binary+0x43a/0x65e<br /> [] bprm_execve+0x1d4/0x316<br /> [] do_execveat_common+0x12e/0x138<br /> [] __riscv_sys_execve+0x38/0x4e<br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> This is an arcane bug but we should still fix it.<br /> <br /> Count down from MAX_ARG_PAGES so the loop ends when index reaches stop,<br /> stop == 0 included. The iterations performed are unchanged for every<br /> other value of stop.<br /> <br /> Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used<br /> by binfmt_flat and binfmt_elf_fdpic on nommu only.<br /> <br /> The loop predates git history. commit 7e7ec6a93434<br /> ("elf_fdpic_transfer_args_to_stack(): make it generic") only moved it<br /> from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used<br /> part of the first page. The condition and the decrement are unchanged<br /> from 2.6.12-rc2.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: wait on ublk_dev_ready() instead of ub-&gt;completion<br /> <br /> ub-&gt;completion is only re-armed by a successful START_USER_RECOVERY. If<br /> the ublk server sends END_USER_RECOVERY without one - e.g. its START<br /> failed with -EBUSY and the error was ignored - the wait is satisfied by<br /> the stale completion of the previous recovery cycle, and the device is<br /> marked LIVE and the requeue list kicked while the FETCH stream is still<br /> running and ubq-&gt;canceling is still set. The kick redispatches a<br /> previously requeued request, __ublk_queue_rq_common() sees -&gt;canceling<br /> and parks it again via __ublk_abort_rq(), and after the last FETCH<br /> clears -&gt;canceling nothing ever kicks the requeue list again: the<br /> request is stranded there while holding its tag. If it is the flush<br /> machinery&amp;#39;s flush_rq, every subsequent fsync piles up in uninterruptible<br /> sleep and teardown hangs on tag draining. This matches a report of a<br /> lost PREFLUSH with ext4 on top of ublk after daemon crash recovery.<br /> <br /> ub-&gt;completion is an edge-triggered latch used as a proxy for the level<br /> condition "every queue has fetched all I/O commands", which can regress<br /> (F_BATCH&amp;#39;s UNPREP, daemon death) and whose re-arm can be skipped. Drop<br /> it and wait on the real condition instead: the new helper<br /> ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via<br /> wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then<br /> re-checks it under ub-&gt;mutex, waiting again on regression, and returns<br /> with the mutex held and readiness guaranteed.<br /> <br /> Readiness becomes true in the same ub-&gt;mutex critical section that<br /> clears the last queue&amp;#39;s -&gt;canceling, so END_USER_RECOVERY marks the<br /> device LIVE and kicks the requeue list strictly after -&gt;canceling<br /> clears. The wait stays interruptible, so a server whose daemon died can<br /> still be signalled out. For ublk_ctrl_start_dev() this replaces the<br /> fail-fast -EINVAL on an F_BATCH ready-&gt;UNPREP regression with waiting<br /> until the device is ready again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix union collision of module and refcnt for dynamic events<br /> <br /> In &amp;#39;struct trace_event_call&amp;#39;, the &amp;#39;module&amp;#39; pointer and the &amp;#39;refcnt&amp;#39;<br /> atomic variable share the same memory space in a union. For dynamic<br /> events, the union member is &amp;#39;refcnt&amp;#39;, which acts as an active<br /> reference counter.<br /> <br /> When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or<br /> wprobe) has a non-zero reference count (e.g. due to active event<br /> triggers or perf attachments), its &amp;#39;call-&gt;module&amp;#39; evaluates to a<br /> small non-zero integer instead of NULL.<br /> <br /> When filtering or setting events for a specific module (e.g., writing<br /> &amp;#39;:mod:&amp;#39; to &amp;#39;set_event&amp;#39;), the code in<br /> &amp;#39;__ftrace_set_clr_event_nolock()&amp;#39; and &amp;#39;update_event_fields()&amp;#39; reads<br /> &amp;#39;call-&gt;module&amp;#39; directly without checking whether the event is dynamic.<br /> This causes the kernel to treat the small integer (refcnt) as a<br /> &amp;#39;struct module&amp;#39; pointer, leading to a NULL/invalid pointer dereference<br /> (Oops) when dereferencing the module name.<br /> <br /> Fix this by ensuring that the &amp;#39;TRACE_EVENT_FL_DYNAMIC&amp;#39; flag is checked<br /> before treating &amp;#39;call-&gt;module&amp;#39; as a valid pointer in these code paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Delay module ref count for "enable_event" trigger<br /> <br /> Triggers are now delayed from freeing, but can still be triggered until<br /> after the RCU grace period has ended. The freeing of the enable_event data<br /> is put into the private_data_free() callback, but the put of the module<br /> refcount is done immediately.<br /> <br /> It is possible that if a module is removed that has an event that would<br /> enable (or disable) it is still active, it can read the data of the module<br /> after it is removed causing a use-after-free bug.<br /> <br /> Move the trace_event_put_ref() that releases the module into the delayed<br /> callback so that the module can not be removed until any reference to its<br /> events are finished.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: nsm: pin the module while the device is open<br /> <br /> misc_open() installs a misc driver&amp;#39;s file operations with fops_get(),<br /> which pins file_operations::owner before replacing the file&amp;#39;s f_op. The<br /> NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does<br /> not take a module reference on the nsm driver.<br /> <br /> If the driver is built as a module, an open file descriptor can therefore<br /> survive rmmod of the module that provides its ioctl callbacks. A later<br /> ioctl through that descriptor can call into unloaded module text.<br /> <br /> Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module<br /> while any /dev/nsm file descriptor is open, matching the lifetime<br /> expectation for the installed file operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: nsm: only unlock nsm_dev on post-lock error paths<br /> <br /> nsm_dev_ioctl() jumps to the common out label even when the initial<br /> copy_from_user() fails before nsm-&gt;lock has been taken. The error path<br /> then blindly unlocks a mutex that was never acquired.<br /> <br /> This issue was found by our static analysis tool and then manually<br /> reviewed against the current tree.<br /> <br /> The grounded PoC kept the miscdevice ioctl entry and the pre-lock<br /> copy_from_user(&amp;raw, argp, _IOC_SIZE(cmd)) failure path by issuing<br /> NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the<br /> shared out label before mutex_lock(&amp;nsm-&gt;lock). Lockdep reported:<br /> <br /> WARNING: bad unlock balance detected!<br /> exploit/193 is trying to release lock (&amp;global_nsm.lock) at:<br /> nsm_dev_ioctl+0x5f/0xcf [vuln_msv]<br /> but there are no more locks to release!<br /> no locks held by exploit/193.<br /> <br /> Return immediately on the pre-lock copy_from_user() failure and keep the<br /> common unlock label for the post-lock paths only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix resource leak on mmiotrace trace_pipe close<br /> <br /> The mmiotrace tracer was added May 12th 2008. At that time, resources<br /> created in pipe_open() could not be freed because there was not<br /> pipe_close function pointer of the tracer. The pipe_close function pointer<br /> was added in December 7th, 2009, but the mmiotrace tracer was not updated.<br /> <br /> mmio_pipe_open() allocates a header_iter and takes a pci_dev reference<br /> when trace_pipe is opened. mmio_close() frees them, but it was only<br /> wired to the tracer&amp;#39;s .close callback.<br /> <br /> tracing_release_pipe() invokes .pipe_close, not .close, when the<br /> trace_pipe file is released. As a result, closing trace_pipe with the<br /> mmiotrace tracer active leaked the header_iter allocation and left a<br /> stale pci_dev reference.<br /> <br /> Set .pipe_close to mmio_close, matching how function_graph wires both<br /> callbacks to the same handler.<br /> <br /> Note, if the trace_pipe is read to completion, it will clean up the<br /> resources, but if one were to run:<br /> <br /> # head -n 1 /sys/kernel/tracing/trace_pipe<br /> VERSION 20070824<br /> <br /> Over and over again, it would trigger a massive leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix mmiotrace possible NULL dereferencing of hiter-&gt;dev<br /> <br /> If the mmio_pipe_open() fails to find a PCI device, the hiter-&gt;dev<br /> will be assigned to NULL. The mmiotrace read() function dereferences the<br /> hiter-&gt;dev if hiter exists.<br /> <br /> Change the test of the read to not only check hiter being NULL, but also<br /> the hiter-&gt;dev before dereferencing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> intel_th: fix MSC output device reference leak<br /> <br /> intel_th_output_open() looks up the output device with<br /> bus_find_device_by_devt(), which returns the device with a reference that<br /> must be dropped after use.<br /> <br /> commit 95fc36a234da ("intel_th: fix device leak on output open()")<br /> attempted to drop the reference from intel_th_output_release(). However,<br /> a successful open replaces file-&gt;f_op with the output driver file<br /> operations before returning, so close runs the output driver release<br /> callback instead.<br /> <br /> For MSC outputs, close runs intel_th_msc_release(), which only removes<br /> the per-file iterator and does not drop the device reference taken by<br /> intel_th_output_open(). Consequently, every successful MSC output open<br /> leaks one device reference.<br /> <br /> Drop the device reference from intel_th_msc_release(), which is the<br /> release path actually used for MSC output files. Remove the now-unused<br /> intel_th_output_release() callback from intel_th_output_fops.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> userfaultfd: prevent registration of special VMAs<br /> <br /> Vova Tokarev says:<br /> <br /> userfaultfd allows registration on shadow stack VMAs. With userfaultfd<br /> access, you can register on the shadow stack, discard a page ... and<br /> inject a page with chosen return addresses via UFFDIO_COPY.<br /> <br /> Update vma_can_userfault() to reject VM_SHADOW_STACK.<br /> <br /> While on it, also reject VM_SPECIAL so that if a driver would implement<br /> vm_uffd_ops, it wouldn&amp;#39;t be possible to register special VMAs with<br /> userfaultfd.<br /> <br /> Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude<br /> hugetlb VMAs from the check for VM_SPECIAL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not try compression for data reloc inodes<br /> <br /> [BUG]<br /> There is a syzbot report that the check inside get_new_location()<br /> triggered:<br /> <br /> BTRFS info (device loop0): found 31 extents, stage: move data extents<br /> BTRFS info (device loop0): leaf 8908800 gen 16 total ptrs 28 free space 1676 owner 18446744073709551607<br /> item 0 key (256 INODE_ITEM 0) itemoff 3835 itemsize 160<br /> inode generation 5 transid 0 size 0 nbytes 0<br /> block group 0 mode 40755 links 1 uid 0 gid 0<br /> rdev 0 sequence 0 flags 0x0<br /> atime 1669132761.0<br /> ctime 1669132761.0<br /> mtime 1669132761.0<br /> otime 0.0<br /> item 1 key (256 INODE_REF 256) itemoff 3823 itemsize 12<br /> index 0 name_len 2<br /> item 2 key (258 INODE_ITEM 0) itemoff 3663 itemsize 160<br /> inode generation 1 transid 16 size 733184 nbytes 106496<br /> block group 0 mode 100600 links 0 uid 0 gid 0<br /> rdev 0 sequence 24 flags 0x18<br /> item 3 key (258 EXTENT_DATA 0) itemoff 3595 itemsize 68<br /> generation 16 type 0<br /> inline extent data size 47 ram_bytes 4096 compression 1<br /> [...]<br /> item 27 key (18446744073709551611 ORPHAN_ITEM 258) itemoff 2376 itemsize 0<br /> BTRFS error (device loop0): unexpected non-zero offset in file extent item for data reloc inode 258 key offset 0 offset 9277520992061368337<br /> ------------[ cut here ]------------<br /> btrfs_abort_should_print_stack(__error)<br /> <br /> [CAUSE]<br /> The above dump tree shows the first file extent item is inlined, which<br /> should make no sense for data reloc inodes, as such inodes just<br /> represent where the data extents are in the relocation destination chunk.<br /> <br /> However the relocation path preallocates space for each block,<br /> then dirties them, cluster by cluster.<br /> It&amp;#39;s possible to have a single block at the beginning of the block<br /> group, and no other block in the same cluster.<br /> <br /> So relocation will preallocate a file extent for that block and dirty<br /> the first block. Then memory pressure forces the data reloc inode to be<br /> written back, before any other blocks are dirtied/allocated.<br /> <br /> Finally commit 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated<br /> delalloc helper") changed the sequence of delalloc. Before that commit we<br /> always tried NOCOW first, so that dirtied block would be written back into<br /> the preallocated space, and appear as a regular extent.<br /> <br /> But with that commit, we always try inline first, and since compression<br /> is forced, we try compressing the first block, and then inline the<br /> compressed data, resulting in the above inlined file extent in the data<br /> reloc tree.<br /> <br /> Then the check in get_new_location() will check the file offset, without<br /> checking if the file extent is inlined or not, resulting in the above<br /> failure.<br /> <br /> [FIX]<br /> Do not allow compression for data reloc inodes.<br /> <br /> Since data reloc inode sizes are always block aligned, as long as we do<br /> not compress, @data_len will always be at least one block, and<br /> that will cause can_cow_file_range_inline() to return false, thus no<br /> inlined extent will be created.