Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Reject wrapped offset in kvm_reset_dirty_gfn()<br /> <br /> kvm_reset_dirty_gfn() guards the gfn range with<br /> <br /> if (!memslot || (offset + __fls(mask)) &gt;= memslot-&gt;npages)<br /> return;<br /> <br /> but offset is u64 and the addition is unchecked. The check can be<br /> silently bypassed by a u64 wrap.<br /> <br /> The dirty ring backing those entries is MAP_SHARED at<br /> KVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the<br /> slot and offset fields of any entry between when the kernel pushes<br /> them and when KVM_RESET_DIRTY_RINGS consumes them. On reset,<br /> kvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds<br /> them straight back into this check; only the flags handshake is<br /> treated as the handover, the slot/offset payload is taken on trust.<br /> <br /> Crafting two entries<br /> <br /> entry[i].offset = 0xffffffffffffffc1<br /> entry[i+1].offset = 0<br /> <br /> makes the coalescing loop in kvm_dirty_ring_reset() compute<br /> <br /> delta = (s64)(0 - 0xffffffffffffffc1) = 63<br /> <br /> which falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the<br /> existing mask by setting bit 63. The trailing kvm_reset_dirty_gfn()<br /> call then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63;<br /> the sum is 0 in u64 and the bounds check passes.<br /> <br /> That offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked()<br /> unchanged. On the legacy MMU path -- kvm_memslots_have_rmaps() ==<br /> true, i.e. shadow paging, any VM that has allocated shadow roots, or<br /> a write-tracked slot -- it reaches gfn_to_rmap(), which indexes<br /> slot-&gt;arch.rmap[0][] with a near-U64_MAX gfn. That is an<br /> out-of-bounds load of a kvm_rmap_head, followed by a conditional<br /> clear of PT_WRITABLE_MASK in whatever the loaded pointer points at.<br /> The path is reachable from any process holding /dev/kvm.<br /> <br /> Range-check offset on its own first, so the addition cannot wrap.<br /> memslot-&gt;npages is bounded well below U64_MAX, so once offset

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetic<br /> <br /> kvm_s390_pci_aif_enable(), kvm_s390_pci_aif_disable(), and<br /> aen_host_forward() index the GAIT by manually multiplying the index<br /> with sizeof(struct zpci_gaite).<br /> <br /> Since aift-&gt;gait is already a struct zpci_gaite pointer, this<br /> double-scales the offset, accessing element aisb*16 instead of aisb.<br /> <br /> This causes out-of-bounds accesses when aisb &gt;= 32 (with<br /> ZPCI_NR_DEVICES=512)<br /> <br /> Fix by removing the erroneous sizeof multiplication.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tls: fix strparser anchor skb leak on offload RX setup failure<br /> <br /> When tls_set_device_offload_rx() fails at tls_dev_add(), the error path<br /> calls tls_sw_free_resources_rx() to clean up the SW context that was<br /> initialized by tls_set_sw_offload(). This function calls<br /> tls_sw_release_resources_rx() (which stops the strparser via<br /> tls_strp_stop()) and tls_sw_free_ctx_rx() (which kfrees the context),<br /> but never frees the anchor skb that was allocated by alloc_skb(0) in<br /> tls_strp_init().<br /> <br /> Note that tls_sw_free_resources_rx() is exclusively used for this<br /> "failed to start offload" code path, there&amp;#39;s no other caller.<br /> <br /> The leak did not exist before commit 84c61fe1a75b ("tls: rx: do not use<br /> the standard strparser"), because the standard strparser doesn&amp;#39;t try<br /> to pre-allocate an skb.<br /> <br /> The normal close path in tls_sk_proto_close() handles cleanup by calling<br /> tls_sw_strparser_done() (which calls tls_strp_done()) after dropping<br /> the socket lock, because tls_strp_done() does cancel_work_sync() and<br /> the strparser work handler takes the socket lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ena: PHC: Fix potential use-after-free in get_timestamp<br /> <br /> Move the phc-&gt;active check and resp pointer assignment to after<br /> acquiring the spinlock. Previously, phc-&gt;active was checked without<br /> holding the lock, and resp was cached from ena_dev-&gt;phc.virt_addr<br /> before the lock was acquired.<br /> <br /> If ena_com_phc_destroy() runs between the lockless active check and<br /> the lock acquisition, it sets active=false, releases the lock, frees<br /> the DMA memory, and sets virt_addr=NULL. The get_timestamp path would<br /> then read a NULL virt_addr and dereference it.<br /> <br /> With both the active check and the pointer read under the lock,<br /> destroy cannot free the memory while get_timestamp is using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_ct: fix missing expect put in obj eval<br /> <br /> nft_ct_expect_obj_eval() allocates an expectation and may call<br /> nf_ct_expect_related(), but never drops its local reference.<br /> <br /> Add nf_ct_expect_put(exp) before return to balance allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/client: fix possible infinite loop and oob read in symlink_data()<br /> <br /> On 32-bit architectures, the infinite loop is as follows:<br /> <br /> len = p-&gt;ErrorDataLength == 0xfffffff8<br /> u8 *next = p-&gt;ErrorContextData + len<br /> next == p<br /> <br /> On 32-bit architectures, the out-of-bounds read is as follows:<br /> <br /> len = p-&gt;ErrorDataLength == 0xfffffff0<br /> u8 *next = p-&gt;ErrorContextData + len<br /> next == (u8 *)p - 8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Replace old pointer to new idr<br /> <br /> Commit 5e28b7b94408 introduced a logical error by failing to replace the<br /> newly generated IDR pointer to old id&amp;#39;s pointer at the correct location<br /> within the "change handle" logic; this resulted in the issue reported by<br /> syzbot [1].<br /> <br /> Specifically, the new IDR object pointer is intended to replace the original<br /> id&amp;#39;s pointer during the normal execution flow.<br /> <br /> Additionally, an unnecessary conditional check for the ret exit path has<br /> been removed.<br /> <br /> [1]<br /> !RB_EMPTY_ROOT(&amp;prime_fpriv-&gt;dmabufs)<br /> WARNING: drivers/gpu/drm/drm_prime.c:224 at drm_prime_destroy_file_private+0x48/0x60 drivers/gpu/drm/drm_prime.c:224, CPU#0: syz.0.17/5833<br /> Call Trace:<br /> drm_file_free.part.0+0x7e6/0xcc0 drivers/gpu/drm/drm_file.c:269<br /> drm_file_free drivers/gpu/drm/drm_file.c:237 [inline]<br /> drm_close_helper.isra.0+0x186/0x200 drivers/gpu/drm/drm_file.c:290<br /> drm_release+0x1ab/0x360 drivers/gpu/drm/drm_file.c:438

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af_alg - Cap AEAD AD length to 0x80000000<br /> <br /> In order to prevent arithmetic overflows when checking the TX<br /> buffer size, cap the associated data length to 0x80000000.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> futex: Drop CLONE_THREAD requirement for private default hash alloc<br /> <br /> Currently need_futex_hash_allocate_default() depends on strict pthread<br /> semantics, abusing CLONE_THREAD. This breaks the non-concurrency<br /> assumptions when doing the mm-&gt;futex_ref pcpu allocations, leading to<br /> bugs[0] when sharing the mm in other ways; ie:<br /> <br /> BUG: KASAN: slab-use-after-free in futex_hash_put<br /> <br /> ... where the +1 bias can end up on a percpu counter that mm-&gt;futex_ref<br /> no longer points at.<br /> <br /> Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding<br /> vfork keeps the existing paths untouched (no overhead), and we can&amp;#39;t<br /> race in the first place: either the parent is suspended and the child<br /> runs alone, or mm-&gt;futex_ref is already allocated from an earlier<br /> CLONE_VM.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans<br /> <br /> The USB MIDI 2.0 endpoint parser has the same descriptor walking<br /> pattern as the legacy MIDI parser. It validates bLength against<br /> bNumGrpTrmBlock before reading baAssoGrpTrmBlkID[], but not against the<br /> remaining bytes in the endpoint-extra scan.<br /> <br /> A malformed device can therefore make later baAssoGrpTrmBlkID[] reads<br /> consume bytes past the walked descriptor.<br /> <br /> Reject zero-length and overlong descriptors while walking endpoint<br /> extras.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Bound MIDI endpoint descriptor scans<br /> <br /> snd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint<br /> descriptor size before using baAssocJackID[], but the descriptor walker can<br /> still return a class-specific endpoint descriptor whose bLength exceeds the<br /> remaining bytes in the endpoint-extra scan.<br /> <br /> That leaves later flexible-array reads bounded by bLength, but not by the<br /> remaining bytes in the endpoint-extra scan.<br /> <br /> Stop walking when bLength is zero or<br /> extends past the remaining endpoint-extra scan.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix a buffer leak in __ceph_setxattr()<br /> <br /> The old_blob in __ceph_setxattr() can store<br /> ci-&gt;i_xattrs.prealloc_blob value during the retry.<br /> However, it is never called the ceph_buffer_put()<br /> for the old_blob object. This patch fixes the issue of<br /> the buffer leak.