Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain()<br /> <br /> In the drain loop, the local variable &amp;#39;runtime&amp;#39; is reassigned to a<br /> linked stream&amp;#39;s runtime (runtime = s-&gt;runtime at line 2157). After<br /> releasing the stream lock at line 2169, the code accesses<br /> runtime-&gt;no_period_wakeup, runtime-&gt;rate, and runtime-&gt;buffer_size<br /> (lines 2170-2178) — all referencing the linked stream&amp;#39;s runtime without<br /> any lock or refcount protecting its lifetime.<br /> <br /> A concurrent close() on the linked stream&amp;#39;s fd triggers<br /> snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private()<br /> → snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime).<br /> No synchronization prevents kfree(runtime) from completing while the<br /> drain path dereferences the stale pointer.<br /> <br /> Fix by caching the needed runtime fields (no_period_wakeup, rate,<br /> buffer_size) into local variables while still holding the stream lock,<br /> and using the cached values after the lock is released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Fix memory leak in xhci_disable_slot()<br /> <br /> xhci_alloc_command() allocates a command structure and, when the<br /> second argument is true, also allocates a completion structure.<br /> Currently, the error handling path in xhci_disable_slot() only frees<br /> the command structure using kfree(), causing the completion structure<br /> to leak.<br /> <br /> Use xhci_free_command() instead of kfree(). xhci_free_command() correctly<br /> frees both the command structure and the associated completion structure.<br /> Since the command structure is allocated with zero-initialization,<br /> command-&gt;in_ctx is NULL and will not be erroneously freed by<br /> xhci_free_command().<br /> <br /> This bug was found using an experimental static analysis tool we are<br /> developing. The tool is based on the LLVM framework and is specifically<br /> designed to detect memory management issues. It is currently under<br /> active development and not yet publicly available, but we plan to<br /> open-source it after our research is published.<br /> <br /> The bug was originally detected on v6.13-rc1 using our static analysis<br /> tool, and we have verified that the issue persists in the latest mainline<br /> kernel.<br /> <br /> We performed build testing on x86_64 with allyesconfig using GCC=11.4.0.<br /> Since triggering these error paths in xhci_disable_slot() requires specific<br /> hardware conditions or abnormal state, we were unable to construct a test<br /> case to reliably trigger these specific error paths at runtime.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: Fix NULL pointer dereference when reading portli debugfs files<br /> <br /> Michal reported and debgged a NULL pointer dereference bug in the<br /> recently added portli debugfs files<br /> <br /> Oops is caused when there are more port registers counted in<br /> xhci-&gt;max_ports than ports reported by Supported Protocol capabilities.<br /> This is possible if max_ports is more than maximum port number, or<br /> if there are gaps between ports of different speeds the &amp;#39;Supported<br /> Protocol&amp;#39; capabilities.<br /> <br /> In such cases port-&gt;rhub will be NULL so we can&amp;#39;t reach xhci behind it.<br /> Add an explicit NULL check for this case, and print portli in hex<br /> without dereferencing port-&gt;rhub.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: yurex: fix race in probe<br /> <br /> The bbu member of the descriptor must be set to the value<br /> standing for uninitialized values before the URB whose<br /> completion handler sets bbu is submitted. Otherwise there is<br /> a window during which probing can overwrite already retrieved<br /> data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeouts<br /> <br /> The usbtmc driver accepts timeout values specified by the user in an<br /> ioctl command, and uses these timeouts for some usb_bulk_msg() calls.<br /> Since the user can specify arbitrarily long timeouts and<br /> usb_bulk_msg() uses unkillable waits, call usb_bulk_msg_killable()<br /> instead to avoid the possibility of the user hanging a kernel thread<br /> indefinitely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Check endpoint numbers at parsing Scarlett2 mixer interfaces<br /> <br /> The Scarlett2 mixer quirk in USB-audio driver may hit a NULL<br /> dereference when a malformed USB descriptor is passed, since it<br /> assumes the presence of an endpoint in the parsed interface in<br /> scarlett2_find_fc_interface(), as reported by fuzzer.<br /> <br /> For avoiding the NULL dereference, just add the sanity check of<br /> bNumEndpoints and skip the invalid interface.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: avoid reading the written value in offsets array<br /> <br /> When sending a transaction, its offsets array is first copied into the<br /> target proc&amp;#39;s vma, and then the values are read back from there. This is<br /> normally fine because the vma is a read-only mapping, so the target<br /> process cannot change the value under us.<br /> <br /> However, if the target process somehow gains the ability to write to its<br /> own vma, it could change the offset before it&amp;#39;s read back, causing the<br /> kernel to misinterpret what the sender meant. If the sender happens to<br /> send a payload with a specific shape, this could in the worst case lead<br /> to the receiver being able to privilege escalate into the sender.<br /> <br /> The intent is that gaining the ability to change the read-only vma of<br /> your own process should not be exploitable, so remove this TOCTOU read<br /> even though it&amp;#39;s unexploitable without another Binder bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: check ownership before using vma<br /> <br /> When installing missing pages (or zapping them), Rust Binder will look<br /> up the vma in the mm by address, and then call vm_insert_page (or<br /> zap_page_range_single). However, if the vma is closed and replaced with<br /> a different vma at the same address, this can lead to Rust Binder<br /> installing pages into the wrong vma.<br /> <br /> By installing the page into a writable vma, it becomes possible to write<br /> to your own binder pages, which are normally read-only. Although you&amp;#39;re<br /> not supposed to be able to write to those pages, the intent behind the<br /> design of Rust Binder is that even if you get that ability, it should not<br /> lead to anything bad. Unfortunately, due to another bug, that is not the<br /> case.<br /> <br /> To fix this, store a pointer in vm_private_data and check that the vma<br /> returned by vma_lookup() has the right vm_ops and vm_private_data before<br /> trying to use the vma. This should ensure that Rust Binder will refuse<br /> to interact with any other VMA. The plan is to introduce more vma<br /> abstractions to avoid this unsafe access to vm_ops and vm_private_data,<br /> but for now let&amp;#39;s start with the simplest possible fix.<br /> <br /> C Binder performs the same check in a slightly different way: it<br /> provides a vm_ops-&gt;close that sets a boolean to true, then checks that<br /> boolean after calling vma_lookup(), but this is more fragile<br /> than the solution in this patch. (We probably still want to do both, but<br /> the vm_ops-&gt;close callback will be added later as part of the follow-up<br /> vma API changes.)<br /> <br /> It&amp;#39;s still possible to remap the vma so that pages appear in the right<br /> vma, but at the wrong offset, but this is a separate issue and will be<br /> fixed when Rust Binder gets a vm_ops-&gt;close callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: fix oneway spam detection<br /> <br /> The spam detection logic in TreeRange was executed before the current<br /> request was inserted into the tree. So the new request was not being<br /> factored in the spam calculation. Fix this by moving the logic after<br /> the new range has been inserted.<br /> <br /> Also, the detection logic for ArrayRange was missing altogether which<br /> meant large spamming transactions could get away without being detected.<br /> Fix this by implementing an equivalent low_oneway_space() in ArrayRange.<br /> <br /> Note that I looked into centralizing this logic in RangeAllocator but<br /> iterating through &amp;#39;state&amp;#39; and &amp;#39;size&amp;#39; got a bit too complicated (for me)<br /> and I abandoned this effort.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Limit the length of unkillable synchronous timeouts<br /> <br /> The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in<br /> usbcore allow unlimited timeout durations. And since they use<br /> uninterruptible waits, this leaves open the possibility of hanging a<br /> task for an indefinitely long time, with no way to kill it short of<br /> unplugging the target device.<br /> <br /> To prevent this sort of problem, enforce a maximum limit on the length<br /> of these unkillable timeouts. The limit chosen here, somewhat<br /> arbitrarily, is 60 seconds. On many systems (although not all) this<br /> is short enough to avoid triggering the kernel&amp;#39;s hung-task detector.<br /> <br /> In addition, clear up the ambiguity of negative timeout values by<br /> treating them the same as 0, i.e., using the maximum allowed timeout.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: class: cdc-wdm: fix reordering issue in read code path<br /> <br /> Quoting the bug report:<br /> <br /> Due to compiler optimization or CPU out-of-order execution, the<br /> desc-&gt;length update can be reordered before the memmove. If this<br /> happens, wdm_read() can see the new length and call copy_to_user() on<br /> uninitialized memory. This also violates LKMM data race rules [1].<br /> <br /> Fix it by using WRITE_ONCE and memory barriers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: renesas_usbhs: fix use-after-free in ISR during device removal<br /> <br /> In usbhs_remove(), the driver frees resources (including the pipe array)<br /> while the interrupt handler (usbhs_interrupt) is still registered. If an<br /> interrupt fires after usbhs_pipe_remove() but before the driver is fully<br /> unbound, the ISR may access freed memory, causing a use-after-free.<br /> <br /> Fix this by calling devm_free_irq() before freeing resources. This ensures<br /> the interrupt handler is both disabled and synchronized (waits for any<br /> running ISR to complete) before usbhs_pipe_remove() is called.