Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: comedi_parport: deal with premature interrupt<br /> <br /> Syzbot reported a general protection fault in<br /> `comedi_get_is_subdevice_running()`, which was called from the interrupt<br /> handler `parport_interrupt()` in the "comedi_parport" driver, but it<br /> does not currently have a C reproducer for the problem. It&amp;#39;s<br /> probably due to a premature interrupt for one of two reasons:<br /> <br /> 1. The driver sets up the interrupt handler before the comedi subdevices<br /> used by the interrupt handler have been allocated, but does not<br /> disable the interrupt in the parallel port&amp;#39;s CTRL register first.<br /> 2. The driver uses a user-supplied I/O port base address which Syzbot<br /> would have supplied, but it might not be backed by real parallel port<br /> hardware.<br /> <br /> Change the initialization order in the driver&amp;#39;s comedi "attach" handler<br /> (`parport_attach()`) so that the hardware registers are initialized<br /> before the interrupt handler is requested. This should prevent<br /> premature interrupts occurring for real hardware.<br /> <br /> Also add a test to the interrupt handler to ensure the comedi device is<br /> fully attached and return early if it isn&amp;#39;t.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: stratix10-svc: fix memory leaks and list corruption bugs<br /> <br /> Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error<br /> path. Switch pmem allocation from devm_kzalloc() to kzalloc() with<br /> explicit kfree() in the free path to match its list-managed lifetime.<br /> Remove the erroneous list_del(&amp;svc_data_mem) which corrupted the list head<br /> on failed lookups.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cdrom: fix stack out-of-bounds read in CDROMVOLCTRL<br /> <br /> mmc_ioctl_cdrom_volume() first reads the audio control mode page into a<br /> 32-byte stack buffer with cgc-&gt;buflen set to 24. If the device reports a<br /> block descriptor, the function increases cgc-&gt;buflen to include that<br /> descriptor and reads the page again.<br /> <br /> For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list<br /> by moving cgc-&gt;buffer forward by offset - 8 bytes. This drops the block<br /> descriptor from the outgoing payload and leaves a new 8-byte mode<br /> parameter header in front of the audio control page. However, cgc-&gt;buflen<br /> is left unchanged.<br /> <br /> With a standard 8-byte block descriptor, cgc-&gt;buffer points at buffer + 8<br /> but cgc-&gt;buflen remains 32. cdrom_mode_select() therefore asks the low<br /> level packet path to write 32 bytes from that adjusted pointer, reading 8<br /> bytes past the end of the 32-byte stack buffer.<br /> <br /> This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on<br /> drives that return a non-zero block descriptor length, which helps explain<br /> why it has gone unnoticed. The overread is also sent to the device as<br /> extra MODE SELECT payload, so it may not produce an obvious local failure.<br /> <br /> Reduce cgc-&gt;buflen by the same amount as the buffer pointer adjustment so<br /> the MODE SELECT transfer covers only the intended parameter list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_misc: set have_execfd only once the interpreter is opened<br /> <br /> load_misc_binary() raises bprm-&gt;have_execfd as soon as it sees the &amp;#39;O&amp;#39;<br /> (or &amp;#39;C&amp;#39;) flag. This happens well before it opens the interpreter. If<br /> that open fails the flag stays set on the bprm. binfmt_misc is at the<br /> head of the format list so an interpreter open failure that returns<br /> -ENOEXEC lets the search fall through to a later format. This means it<br /> runs the matched binary directly having never staged an interpreter. So<br /> bprm-&gt;executable is NULL while have_execfd falsely claims a descriptor<br /> is present.<br /> <br /> Consequently, begin_new_exec() dereferences the missing executable:<br /> <br /> would_dump(bprm, bprm-&gt;executable);<br /> <br /> and NULL derefs. Had it not, the hand-off later in the same function<br /> would have failed anyway. FD_ADD(0, bprm-&gt;executable) rejects a NULL<br /> file with -ENOMEM. Both sites are past the point of no return so the<br /> exec cannot be unwound either way.<br /> <br /> This can be reached by unprivileged users as binfmt_misc can be mounted<br /> in user namespaces. So a user can register an &amp;#39;O&amp;#39; entry whose<br /> interpreter lives on a FUSE mount, have the FUSE server fail the open<br /> with -ENOEXEC and execute a native ELF file that matches the entry.<br /> <br /> have_execfd only means anything alongside the executable it describes<br /> which is not set until the interpreter has been opened and staged.<br /> So lets raise it there, next to execfd_creds, which is already set at<br /> that point. An open failure now leaves it clear, so the fallback format<br /> derives credentials from the binary and emits no AT_EXECFD, as it would<br /> for any native exec. The argv rewrite load_misc_binary() performs before<br /> the open is still not undone. This means the binary sees the interpreter<br /> path in argv[0] and its own path in argv[1] but that predates this<br /> change and only became observable once the exec stopped faulting.

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.