In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters
When srpt_alloc_rw_ctxs() fails partway through a multi-buffer indirect
descriptor, the unwind path destroys RDMA contexts but leaves stale
n_rw_ctx and n_rdma values (and a dangling rw_ctxs pointer). Later
sq_wr_avail accounting in srpt_queue_response() or srpt_write_pending()
can then subtract the wrong number of send queue credits.
Reset the counters and clear rw_ctxs after freeing the heap
allocation before returning an error.
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix xmit_frame/xmit_buf leaks on mgnt-frame error paths
issue_beacon(), issue_probersp() and issue_asocrsp() obtain a management
xmit_frame together with its xmit_buf from the driver's fixed-size
management-TX pools via alloc_mgtxmitframe(). On the normal path the frame
is handed to dump_mgntframe(), which transfers ownership and eventually
returns both objects to their pools (the frame and, for beacons, the buf
in rtl8723bs_mgnt_xmit(); other bufs via the pending-xmitbuf/TX-completion
path).
Several error/edge paths return early after a successful
alloc_mgtxmitframe() but before dump_mgntframe(), so ownership is never
transferred and neither object is freed:
- issue_beacon(): beacon larger than 512 bytes
- issue_probersp(): cur_network->ie_length > MAX_IE_SZ
- issue_probersp(): kzalloc() of the SSID scratch buffer fails
- issue_asocrsp(): pkt_type is neither ASSOCRSP nor REASSOCRSP
Because alloc_mgtxmitframe() removes the frame and buf from their free
lists (list_del_init) without placing them on any pending list, an
orphaned pair is on no list and referenced by nobody, so it is only
reclaimed at driver teardown. Repeated hits progressively exhaust the
management-TX pools until alloc_mgtxmitframe() returns NULL and the
interface can no longer send beacons or probe/assoc responses.
Free the frame and buffer on these paths, matching the existing correct
error handling in issue_assocreq().
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Recover HW before retire hung submit
During recovery, it is not safe to retire the hung submit before we
recover the GPU. Retiring the submit triggers BO free and that can
result in GPU pagefaults since the GPU may be actively accessing those
BOs.
To fix this, retire the submits after gpu recovery is complete in
recover_worker().
Patchwork: https://patchwork.freedesktop.org/patch/730655/
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mei: pass correct argument to function
The first argument to iwl_mei_write_cyclic_buf() should be the cldev
but the q_head pointer is passed instead. Fix it.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Mark bpf_refcount field as unique
BPF_REFCOUNT is not marked as a unique field, while it should be. Fix
this oversight.
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: use the DMA API for resource backing on Xen
On a Xen PV domain page addresses bear no relation to the real machine
addresses the host would have to use to reach it.
virtio_ring.c handles this correctly, vring_use_map_api() returns true
for any xen_domain() regardless of VIRTIO_F_ACCESS_PLATFORM.
virtio-gpu makes the same decision independently, but its copy
looks only at the feature bit:
bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);
QEMU does not set iommu_platform on virtio-vga by default, so
VIRTIO_F_ACCESS_PLATFORM is not negotiated, use_dma_api is false, and
virtio_gpu_object_shmem_init() describes the framebuffer's backing pages
to the host with sg_phys(). Those are guest-physical addresses. In a PV
domain they resolve, on the host side, to pages belonging to some other
domain, so the host scans out unrelated memory.
Move the decision into virtio_gpu_use_dma_api() and give it the
xen_domain() check, like vring_use_map_api() has. This
additionally enables the dma_sync_sgtable_for_device() calls in
virtgpu_vq.c, which are required for correctness whenever swiotlb
is in play.
Reproduced with a Xen 4.21 PV dom0 nested inside QEMU 8.2 with
virtio-vga, on both a distro 6.8 kernel and 6.18 LTS. A PVH dom0
works fine and doesn't need this fix because it is identity-mapped,
only PV dom0s are affected.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921: validate CLC firmware records
The CLC region is supplied by firmware, but the loader trusts the
region count and each record length. A malformed image can make the
region table pointer precede the firmware buffer, make the record loop
fail to advance, or index phy->clc past its end. Validate the table and
record bounds before dereferencing or copying.
In the Linux kernel, the following vulnerability has been resolved:
nvmet-rdma: fix queue leak when connect backlog is exceeded
When pending disconnecting queues exceed the backlog limit, the
connect path only drops the device reference and leaks the newly
allocated queue and its IB resources.
In the Linux kernel, the following vulnerability has been resolved:
ntfs: bound $AttrDef table walk to the loaded table size
ntfs_attr_find_in_attrdef() walks the in-memory $AttrDef table, but the
loop condition bounds only the start of each entry, not the whole entry:
for (ad = vol->attrdef; (u8 *)ad - (u8 *)vol->attrdef <
vol->attrdef_size && ad->type; ++ad)
struct attr_def is 160 bytes; the guard reads ad->type at offset 128 and
the loop body reads further fields. vol->attrdef is kvzalloc(i_size),
where i_size is the on-disk $AttrDef data size, checked in
load_and_init_attrdef() only as 0 < i_size <= 0x7fffffff. A volume whose
$AttrDef data size is smaller than one entry (e.g. 120 bytes) makes the
read of ad->type run past the allocation. Creating a file reaches this
through ntfs_attr_size_bounds_check() and reads out of bounds:
BUG: KASAN: slab-out-of-bounds in ntfs_attr_find_in_attrdef+0x66/0xa0
Read of size 4 at addr ffff888005833280 by task init/1
ntfs_attr_find_in_attrdef
ntfs_attr_size_bounds_check
ntfs_attr_can_be_non_resident
ntfs_attr_add
Require the whole entry to lie within attrdef_size in the loop guard, and
reject at mount a $AttrDef too small to hold one attr_def entry.
In the Linux kernel, the following vulnerability has been resolved:
ntfs: treat any nonzero dio zero-range return as an error
ntfs_dio_zero_range() returns either 0 or a negative errno from
blkdev_issue_zeroout(); it never returns a positive value. The
zeroing failure check in ntfs_attr_fallocate() therefore never fired,
so a failed zeroing operation was silently ignored: the loop kept
going, the newly allocated clusters were folded into initialized_size
and the write could succeed leaving stale on-disk data.
Treat any nonzero return as an error and abort the allocation.