Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gic-v3-its: Avoid truncating memory addresses<br /> <br /> On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem<br /> allocations to be backed by addresses physical memory above the 32-bit<br /> address limit, as found while experimenting with larger VMSPLIT<br /> configurations.<br /> <br /> This caused the qemu virt model to crash in the GICv3 driver, which<br /> allocates the &amp;#39;itt&amp;#39; object using GFP_KERNEL. Since all memory below<br /> the 4GB physical address limit is in ZONE_DMA in this configuration,<br /> kmalloc() defaults to higher addresses for ZONE_NORMAL, and the<br /> ITS driver stores the physical address in a 32-bit &amp;#39;unsigned long&amp;#39;<br /> variable.<br /> <br /> Change the itt_addr variable to the correct phys_addr_t type instead,<br /> along with all other variables in this driver that hold a physical<br /> address.<br /> <br /> The gicv5 driver correctly uses u64 variables, while all other irqchip<br /> drivers don&amp;#39;t call virt_to_phys or similar interfaces. It&amp;#39;s expected that<br /> other device drivers have similar issues, but fixing this one is<br /> sufficient for booting a virtio based guest.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: cap TX credit to local buffer size<br /> <br /> The virtio transports derives its TX credit directly from peer_buf_alloc,<br /> which is set from the remote endpoint&amp;#39;s SO_VM_SOCKETS_BUFFER_SIZE value.<br /> <br /> On the host side this means that the amount of data we are willing to<br /> queue for a connection is scaled by a guest-chosen buffer size, rather<br /> than the host&amp;#39;s own vsock configuration. A malicious guest can advertise<br /> a large buffer and read slowly, causing the host to allocate a<br /> correspondingly large amount of sk_buff memory.<br /> The same thing would happen in the guest with a malicious host, since<br /> virtio transports share the same code base.<br /> <br /> Introduce a small helper, virtio_transport_tx_buf_size(), that<br /> returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume<br /> peer_buf_alloc.<br /> <br /> This ensures the effective TX window is bounded by both the peer&amp;#39;s<br /> advertised buffer and our own buf_alloc (already clamped to<br /> buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer<br /> cannot force the other to queue more data than allowed by its own<br /> vsock settings.<br /> <br /> On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with<br /> 32 guest vsock connections advertising 2 GiB each and reading slowly<br /> drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only<br /> recovered after killing the QEMU process. That said, if QEMU memory is<br /> limited with cgroups, the maximum memory used will be limited.<br /> <br /> With this patch applied:<br /> <br /> Before:<br /> MemFree: ~61.6 GiB<br /> Slab: ~142 MiB<br /> SUnreclaim: ~117 MiB<br /> <br /> After 32 high-credit connections:<br /> MemFree: ~61.5 GiB<br /> Slab: ~178 MiB<br /> SUnreclaim: ~152 MiB<br /> <br /> Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest<br /> remains responsive.<br /> <br /> Compatibility with non-virtio transports:<br /> <br /> - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per<br /> socket based on the local vsk-&gt;buffer_* values; the remote side<br /> cannot enlarge those queues beyond what the local endpoint<br /> configured.<br /> <br /> - Hyper-V&amp;#39;s vsock transport uses fixed-size VMBus ring buffers and<br /> an MTU bound; there is no peer-controlled credit field comparable<br /> to peer_buf_alloc, and the remote endpoint cannot drive in-flight<br /> kernel memory above those ring sizes.<br /> <br /> - The loopback path reuses virtio_transport_common.c, so it<br /> naturally follows the same semantics as the virtio transport.<br /> <br /> This change is limited to virtio_transport_common.c and thus affects<br /> virtio-vsock, vhost-vsock, and loopback, bringing them in line with the<br /> "remote window intersected with local policy" behaviour that VMCI and<br /> Hyper-V already effectively have.<br /> <br /> [Stefano: small adjustments after changing the previous patch]<br /> [Stefano: tweak the commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()<br /> <br /> Memory allocated for struct vscsiblk_info in scsiback_probe() is not<br /> freed in scsiback_remove() leading to potential memory leaks on remove,<br /> as well as in the scsiback_probe() error paths. Fix that by freeing it<br /> in scsiback_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix crash on synthetic stacktrace field usage<br /> <br /> When creating a synthetic event based on an existing synthetic event that<br /> had a stacktrace field and the new synthetic event used that field a<br /> kernel crash occurred:<br /> <br /> ~# cd /sys/kernel/tracing<br /> ~# echo &amp;#39;s:stack unsigned long stack[];&amp;#39; &gt; dynamic_events<br /> ~# echo &amp;#39;hist:keys=prev_pid:s0=common_stacktrace if prev_state &amp; 3&amp;#39; &gt;&gt; events/sched/sched_switch/trigger<br /> ~# echo &amp;#39;hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)&amp;#39; &gt;&gt; events/sched/sched_switch/trigger<br /> <br /> The above creates a synthetic event that takes a stacktrace when a task<br /> schedules out in a non-running state and passes that stacktrace to the<br /> sched_switch event when that task schedules back in. It triggers the<br /> "stack" synthetic event that has a stacktrace as its field (called "stack").<br /> <br /> ~# echo &amp;#39;s:syscall_stack s64 id; unsigned long stack[];&amp;#39; &gt;&gt; dynamic_events<br /> ~# echo &amp;#39;hist:keys=common_pid:s2=stack&amp;#39; &gt;&gt; events/synthetic/stack/trigger<br /> ~# echo &amp;#39;hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)&amp;#39; &gt;&gt; events/raw_syscalls/sys_exit/trigger<br /> <br /> The above makes another synthetic event called "syscall_stack" that<br /> attaches the first synthetic event (stack) to the sys_exit trace event and<br /> records the stacktrace from the stack event with the id of the system call<br /> that is exiting.<br /> <br /> When enabling this event (or using it in a historgram):<br /> <br /> ~# echo 1 &gt; events/synthetic/syscall_stack/enable<br /> <br /> Produces a kernel crash!<br /> <br /> BUG: unable to handle page fault for address: 0000000000400010<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP PTI<br /> CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014<br /> RIP: 0010:trace_event_raw_event_synth+0x90/0x380<br /> Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f<br /> RSP: 0018:ffffd2670388f958 EFLAGS: 00010202<br /> RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0<br /> RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50<br /> R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010<br /> R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90<br /> FS: 00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> ? __tracing_map_insert+0x208/0x3a0<br /> action_trace+0x67/0x70<br /> event_hist_trigger+0x633/0x6d0<br /> event_triggers_call+0x82/0x130<br /> trace_event_buffer_commit+0x19d/0x250<br /> trace_event_raw_event_sys_exit+0x62/0xb0<br /> syscall_exit_work+0x9d/0x140<br /> do_syscall_64+0x20a/0x2f0<br /> ? trace_event_raw_event_sched_switch+0x12b/0x170<br /> ? save_fpregs_to_fpstate+0x3e/0x90<br /> ? _raw_spin_unlock+0xe/0x30<br /> ? finish_task_switch.isra.0+0x97/0x2c0<br /> ? __rseq_handle_notify_resume+0xad/0x4c0<br /> ? __schedule+0x4b8/0xd00<br /> ? restore_fpregs_from_fpstate+0x3c/0x90<br /> ? switch_fpu_return+0x5b/0xe0<br /> ? do_syscall_64+0x1ef/0x2f0<br /> ? do_fault+0x2e9/0x540<br /> ? __handle_mm_fault+0x7d1/0xf70<br /> ? count_memcg_events+0x167/0x1d0<br /> ? handle_mm_fault+0x1d7/0x2e0<br /> ? do_user_addr_fault+0x2c3/0x7f0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The reason is that the stacktrace field is not labeled as such, and is<br /> treated as a normal field and not as a dynamic event that it is.<br /> <br /> In trace_event_raw_event_synth() the event is field is still treated as a<br /> dynamic array, but the retrieval of the data is considered a normal field,<br /> and the reference is just the meta data:<br /> <br /> // Meta data is retrieved instead of a dynamic array<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free()<br /> <br /> When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees<br /> mixer-&gt;id_elems but the controls already added to the card still<br /> reference the freed memory. Later when snd_card_register() runs,<br /> the OSS mixer layer calls their callbacks and hits a use-after-free read.<br /> <br /> Call trace:<br /> get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411<br /> get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241<br /> mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381<br /> snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887<br /> ...<br /> snd_card_register+0x4ed/0x6d0 sound/core/init.c:923<br /> usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025<br /> <br /> Fix by calling snd_ctl_remove() for all mixer controls before freeing<br /> id_elems. We save the next pointer first because snd_ctl_remove()<br /> frees the current element.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slimbus: core: fix device reference leak on report present<br /> <br /> Slimbus devices can be allocated dynamically upon reception of<br /> report-present messages.<br /> <br /> Make sure to drop the reference taken when looking up already registered<br /> devices.<br /> <br /> Note that this requires taking an extra reference in case the device has<br /> not yet been registered and has to be allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> intel_th: fix device leak on output open()<br /> <br /> Make sure to drop the reference taken when looking up the th device<br /> during output device open() on errors and on close().<br /> <br /> Note that a recent commit fixed the leak in a couple of open() error<br /> paths but not all of them, and the reference is still leaking on<br /> successful open().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rsi: Fix memory corruption due to not set vif driver data size<br /> <br /> The struct ieee80211_vif contains trailing space for vif driver data,<br /> when struct ieee80211_vif is allocated, the total memory size that is<br /> allocated is sizeof(struct ieee80211_vif) + size of vif driver data.<br /> The size of vif driver data is set by each WiFi driver as needed.<br /> <br /> The RSI911x driver does not set vif driver data size, no trailing space<br /> for vif driver data is therefore allocated past struct ieee80211_vif .<br /> The RSI911x driver does however use the vif driver data to store its<br /> vif driver data structure "struct vif_priv". An access to vif-&gt;drv_priv<br /> leads to access out of struct ieee80211_vif bounds and corruption of<br /> some memory.<br /> <br /> In case of the failure observed locally, rsi_mac80211_add_interface()<br /> would write struct vif_priv *vif_info = (struct vif_priv *)vif-&gt;drv_priv;<br /> vif_info-&gt;vap_id = vap_idx. This write corrupts struct fq_tin member<br /> struct list_head new_flows . The flow = list_first_entry(head, struct<br /> fq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus<br /> address, which when accessed causes a crash.<br /> <br /> The trigger is very simple, boot the machine with init=/bin/sh , mount<br /> devtmpfs, sysfs, procfs, and then do "ip link set wlan0 up", "sleep 1",<br /> "ip link set wlan0 down" and the crash occurs.<br /> <br /> Fix this by setting the correct size of vif driver data, which is the<br /> size of "struct vif_priv", so that memory is allocated and the driver<br /> can store its driver data in it, instead of corrupting memory around<br /> it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Enforce that teql can only be used as root qdisc<br /> <br /> Design intent of teql is that it is only supposed to be used as root qdisc.<br /> We need to check for that constraint.<br /> <br /> Although not important, I will describe the scenario that unearthed this<br /> issue for the curious.<br /> <br /> GangMin Kim managed to concot a scenario as follows:<br /> <br /> ROOT qdisc 1:0 (QFQ)<br /> ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s<br /> └── class 1:2 (weight=1, lmax=1514) teql<br /> <br /> GangMin sends a packet which is enqueued to 1:1 (netem).<br /> Any invocation of dequeue by QFQ from this class will not return a packet<br /> until after 6.4s. In the meantime, a second packet is sent and it lands on<br /> 1:2. teql&amp;#39;s enqueue will return success and this will activate class 1:2.<br /> Main issue is that teql only updates the parent visible qlen (sch-&gt;q.qlen)<br /> at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql&amp;#39;s<br /> peek always returns NULL), dequeue will never be called and thus the qlen<br /> will remain as 0. With that in mind, when GangMin updates 1:2&amp;#39;s lmax value,<br /> the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc&amp;#39;s<br /> qlen was not incremented, qfq fails to deactivate the class, but still<br /> frees its pointers from the aggregate. So when the first packet is<br /> rescheduled after 6.4 seconds (netem&amp;#39;s delay), a dangling pointer is<br /> accessed causing GangMin&amp;#39;s causing a UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak<br /> <br /> Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:<br /> gs_usb_receive_bulk_callback(): fix URB memory leak").<br /> <br /> In esd_usb_open(), the URBs for USB-in transfers are allocated, added to<br /> the dev-&gt;rx_submitted anchor and submitted. In the complete callback<br /> esd_usb_read_bulk_callback(), the URBs are processed and resubmitted. In<br /> esd_usb_close() the URBs are freed by calling<br /> usb_kill_anchored_urbs(&amp;dev-&gt;rx_submitted).<br /> <br /> However, this does not take into account that the USB framework unanchors<br /> the URB before the complete function is called. This means that once an<br /> in-URB has been completed, it is no longer anchored and is ultimately not<br /> released in esd_usb_close().<br /> <br /> Fix the memory leak by anchoring the URB in the<br /> esd_usb_read_bulk_callback() to the dev-&gt;rx_submitted anchor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ctxfi: Fix potential OOB access in audio mixer handling<br /> <br /> In the audio mixer handling code of ctxfi driver, the conf field is<br /> used as a kind of loop index, and it&amp;#39;s referred in the index callbacks<br /> (amixer_index() and sum_index()).<br /> <br /> As spotted recently by fuzzers, the current code causes OOB access at<br /> those functions.<br /> | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48<br /> | index 8 is out of range for type &amp;#39;unsigned char [8]&amp;#39;<br /> <br /> After the analysis, the cause was found to be the lack of the proper<br /> (re-)initialization of conj field.<br /> <br /> This patch addresses those OOB accesses by adding the proper<br /> initializations of the loop indices.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge<br /> <br /> Patch series "mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted<br /> merge", v2.<br /> <br /> Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA<br /> merges") introduced the ability to merge previously unavailable VMA merge<br /> scenarios.<br /> <br /> However, it is handling merges incorrectly when it comes to mremap() of a<br /> faulted VMA adjacent to an unfaulted VMA. The issues arise in three<br /> cases:<br /> <br /> 1. Previous VMA unfaulted:<br /> <br /> copied -----|<br /> v<br /> |-----------|.............|<br /> | unfaulted |(faulted VMA)|<br /> |-----------|.............|<br /> prev<br /> <br /> 2. Next VMA unfaulted:<br /> <br /> copied -----|<br /> v<br /> |.............|-----------|<br /> |(faulted VMA)| unfaulted |<br /> |.............|-----------|<br /> next<br /> <br /> 3. Both adjacent VMAs unfaulted:<br /> <br /> copied -----|<br /> v<br /> |-----------|.............|-----------|<br /> | unfaulted |(faulted VMA)| unfaulted |<br /> |-----------|.............|-----------|<br /> prev next<br /> <br /> This series fixes each of these cases, and introduces self tests to assert<br /> that the issues are corrected.<br /> <br /> I also test a further case which was already handled, to assert that my<br /> changes continues to correctly handle it:<br /> <br /> 4. prev unfaulted, next faulted:<br /> <br /> copied -----|<br /> v<br /> |-----------|.............|-----------|<br /> | unfaulted |(faulted VMA)| faulted |<br /> |-----------|.............|-----------|<br /> prev next<br /> <br /> This bug was discovered via a syzbot report, linked to in the first patch<br /> in the series, I confirmed that this series fixes the bug.<br /> <br /> I also discovered that we are failing to check that the faulted VMA was<br /> not forked when merging a copied VMA in cases 1-3 above, an issue this<br /> series also addresses.<br /> <br /> I also added self tests to assert that this is resolved (and confirmed<br /> that the tests failed prior to this).<br /> <br /> I also cleaned up vma_expand() as part of this work, renamed<br /> vma_had_uncowed_parents() to vma_is_fork_child() as the previous name was<br /> unduly confusing, and simplified the comments around this function.<br /> <br /> <br /> This patch (of 4):<br /> <br /> Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA<br /> merges") introduced the ability to merge previously unavailable VMA merge<br /> scenarios.<br /> <br /> The key piece of logic introduced was the ability to merge a faulted VMA<br /> immediately next to an unfaulted VMA, which relies upon dup_anon_vma() to<br /> correctly handle anon_vma state.<br /> <br /> In the case of the merge of an existing VMA (that is changing properties<br /> of a VMA and then merging if those properties are shared by adjacent<br /> VMAs), dup_anon_vma() is invoked correctly.<br /> <br /> However in the case of the merge of a new VMA, a corner case peculiar to<br /> mremap() was missed.<br /> <br /> The issue is that vma_expand() only performs dup_anon_vma() if the target<br /> (the VMA that will ultimately become the merged VMA): is not the next VMA,<br /> i.e. the one that appears after the range in which the new VMA is to be<br /> established.<br /> <br /> A key insight here is that in all other cases other than mremap(), a new<br /> VMA merge either expands an existing VMA, meaning that the target VMA will<br /> be that VMA, or would have anon_vma be NULL.<br /> <br /> Specifically:<br /> <br /> * __mmap_region() - no anon_vma in place, initial mapping.<br /> * do_brk_flags() - expanding an existing VMA.<br /> * vma_merge_extend() - expanding an existing VMA.<br /> * relocate_vma_down() - no anon_vma in place, initial mapping.<br /> <br /> In addition, we are in the unique situation of needing to duplicate<br /> anon_vma state from a VMA that is neither the previous or next VMA being<br /> merged with.<br /> <br /> dup_anon_vma() deals exclusively with the target=unfaulted, src=faulted<br /> case. This leaves four possibilities, in each case where the copied VMA<br /> is faulted:<br /> <br /> 1. Previous VMA unfaulted:<br /> <br /> copied -----|<br /> <br /> ---truncated---