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 /> LoongArch: Move jump_label_init() before parse_early_param()<br /> <br /> When enabling both CONFIG_MEM_ALLOC_PROFILING=y and<br /> CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y, then diabling memory<br /> profiling by adding the boot parameter &amp;#39;sysctl.vm.mem_profiling=0&amp;#39; will<br /> cause the kernel failed to boot.<br /> <br /> After analysis, this is because jump_label_init() must be called before<br /> parse_early_param(), the early param handlers may modify static keys by<br /> static_branch_enable/disable().<br /> <br /> Fix this by moving jump_label_init() to before parse_early_param(). The<br /> solution is similar to other architectures.

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.