| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/vf: Add drm_dev guards when detaching CCS read/write buffers
CCS read/write buffers are freed during BO destruction. In some cases,
BOs may be destroyed after the device is unbound but while the DRM
structure remains valid, leading to NULL pointer dereferences when
accessing device resources.
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 9376 Comm: xe_pat Not tainted 7.2.0-rc2+ #1 PREEMPT(lazy)
RIP: 0010:xe_sriov_vf_ccs_rw_update_bb_addr+0x4d/0xa0 [xe]
RSP: 0018:ffffcf304110b9c8 EFLAGS: 00010246
RAX: ffff8a85c38a0a00 RBX: 00000000810ef000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8a85c39c1888
RBP: ffffcf304110b9e8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a85c39c1888
R13: 0000000000000000 R14: ffff8a85c39b4f28 R15: ffff8a85c3885000
FS: 0000000000000000(0000) GS:ffff8a878b809000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000010314a002 CR4: 0000000000772ef0
PKRU: 55555554
Call Trace:
<TASK>
xe_migrate_ccs_rw_copy_clear+0x98/0x120 [xe]
xe_sriov_vf_ccs_detach_bo+0x2c/0x60 [xe]
xe_ttm_bo_delete_mem_notify+0xc8/0xe0 [xe]
ttm_bo_cleanup_memtype_use+0x26/0x80 [ttm]
ttm_bo_release+0x29e/0x2d0 [ttm]
ttm_bo_fini+0x39/0x70 [ttm]
xe_gem_object_free+0x1f/0x30 [xe]
drm_gem_object_free+0x1d/0x40
ttm_bo_vm_close+0x5f/0x90 [ttm]
remove_vma+0x2c/0x70
tear_down_vmas+0x63/0xf0
exit_mmap+0x20d/0x3f0
__mmput+0x45/0x170
mmput+0x31/0x40
do_exit+0x2ba/0xac0
do_group_exit+0x2d/0xb0
__x64_sys_exit_group+0x18/0x20
x64_sys_call+0x14a0/0x2390
do_syscall_64+0xdd/0x640
? count_memcg_events+0xea/0x240
? handle_mm_fault+0x1ec/0x2f0
(cherry picked from commit 1ae415a6eefe5004954a1d352b1718faca8844ef) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()
Commit 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") made
xe_svm_init() unconditional in xe_vm_create() and extended it to also
initialize a "simple" gpusvm state for non-fault-mode VMs. The matching
xe_svm_fini() call in xe_vm_close_and_put() was updated to run
unconditionally, but the error unwind path in xe_vm_create() was not.
On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has
already succeeded but xe_svm_fini() is only called when
XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves
vm->svm.gpusvm partially initialized and leaks the resources allocated
by drm_gpusvm_init().
For fault-mode VMs, xe_svm_init() additionally acquires the pagemap
owner via drm_pagemap_acquire_owner() and the pagemaps via
xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(),
not xe_svm_fini(). On the same error path, xe_svm_close() is not
called either, so fault-mode VMs leak the pagemap owner and pagemaps.
Fix both leaks:
- Call xe_svm_fini() unconditionally on the err_svm_fini path, matching
the unconditional xe_svm_init() call. Move the vm->size = 0
assignment out of the conditional so the xe_vm_is_closed() assert in
xe_svm_fini() (and xe_svm_close()) holds for both modes.
- Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching
the ordering used in xe_vm_close_and_put().
(cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4) |
| In the Linux kernel, the following vulnerability has been resolved:
net: qrtr: restrict socket creation to the initial network namespace
QRTR keeps its entire port and node state in module-global variables
that are not partitioned per network namespace: qrtr_local_nid is a
single global node id (always 1) and qrtr_ports is a single global
xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that
global state with no network-namespace check, and qrtr_create() places
no restriction on the namespace a socket is created in.
As a result an unprivileged process that creates an AF_QIPCRTR socket
in a separate network namespace, e.g. via
unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams -
including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR
sockets owned by another namespace, and vice versa. The receiving
socket sees such a message as coming from node id 1, indistinguishable
from a legitimate local client, breaking the isolation that network
namespaces are expected to provide.
QRTR is a transport to global hardware endpoints (the modem and other
remote processors) and has no per-namespace semantics; its in-kernel
name service already creates its socket in init_net only. Confine the
socket family to the initial network namespace, as other
non-namespace-aware socket families do (see llc_ui_create() and the
ieee802154 socket code). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/guc: Fix buffer overflow in steered register list allocation
The size calculation for the steered register extarray uses only the
geometry DSS mask (g_dss_mask) to determine the number of entries to
allocate:
total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num;
However, the filling loop uses for_each_dss_steering(), which iterates
over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask
(geometry + compute DSS). On platforms with compute-only DSS bits, the
loop writes past the allocated buffer, corrupting adjacent slab objects.
This manifests as list_del corruption and SLUB redzone overwrites during
drm_managed_release on device unbind, since the overflow corrupts the
drmres list_head of neighboring allocations.
Fix by computing the allocation size using the union of both DSS masks,
matching the iteration pattern of for_each_dss_steering().
--
v2:
- use bitmap_weighted_or() (Zhanjun)
(cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f) |
| In the Linux kernel, the following vulnerability has been resolved:
net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()
afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC.
If the allocation fails, nsk is NULL.
The connection-refused path is entered when the listen state check
fails, the accept backlog is full, or nsk is NULL. The code
unconditionally calls iucv_sock_kill(nsk) in that path.
iucv_sock_kill() does not accept a NULL socket pointer and immediately
dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL,
calling iucv_sock_kill(nsk) results in a NULL pointer dereference.
Only call iucv_sock_kill() when a child socket was successfully
allocated. |
| In the Linux kernel, the following vulnerability has been resolved:
ice: reject out-of-range ptype in ice_parser_profile_init
set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of
ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from
providing ptype >= 1024 through VIRTCHNL, resulting in a write past
the end of the bitmap and a kernel page fault.
Reproduced with a custom kernel module injecting a crafted
VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592),
FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0,
kernel 7.1.0-rc1.
crash_parser: ice_parser_profile_init @ ffffffffc0d61b60
crash_parser: setting ptype=0xffff (max valid=1023)
crash_parser: calling ice_parser_profile_init -- expect OOB crash!
BUG: kernel NULL pointer dereference, address: 0000000000000000
Oops: Oops: 0002 [#1] SMP NOPTI
CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1
Hardware name: Intel Corporation S2600BPB/S2600BPB
RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice]
Call Trace:
<TASK>
? __pfx_ice_parser_profile_init+0x10/0x10 [ice]
crash_init+0x127/0xff0 [crash_parser]
do_one_initcall+0x45/0x310
do_init_module+0x64/0x270
init_module_from_file+0xcc/0xf0
idempotent_init_module+0x17b/0x280
__x64_sys_finit_module+0x6e/0xe0
Bail out early with -EINVAL when ptype is out of range. |
| In modem, there is a possible information disclosure due to missing filtering of sensitive data in crash dumps. This could lead to local information disclosure with no additional execution privileges needed. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: drain bus_reset work on device removal
brcmf_fw_crashed() and the debugfs "reset" entry both schedule
drvr->bus_reset, whose callback recovers drvr through container_of()
and dereferences it. The removal path frees drvr (brcmf_free ->
wiphy_free) without draining the work, so a bus_reset callback pending
or running during removal can outlive drvr.
Cancellation cannot live in brcmf_detach() or brcmf_free(): the work
callback reaches teardown through the bus .reset op (PCIe
brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset ->
brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for
the running work and deadlock.
Add a per-bus mutex (bus_reset_lock) and route all arming through
brcmf_bus_schedule_reset(), which under the lock skips when the bus is
marked removing. Each bus remove entry calls
brcmf_bus_cancel_reset_work(), which under the same lock sets removing
and cancels the work. Holding the mutex across cancel_work_sync() makes
the set-removing + drain step atomic. Every producer reaches the arming
path from process context -- the PCIe firmware-halt notification runs in
the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail
path runs from the data workqueue -- so the mutex is taken only in
sleepable contexts. Where applicable the remove entry first stops the
firmware-crash producer: on PCIe mask the mailbox and synchronize_irq;
on SDIO unregister the bus interrupt and cancel the data worker, which
also reports firmware halts through brcmf_fw_crashed(). The mutex is
initialized at bus allocation. The SDIO suspend power-off path frees
drvr through the same brcmf_sdiod_remove() and takes the same lock;
resume re-allows the work only on a successful re-probe.
Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire
before brcmf_attach() wires up drvr, and it dereferences drvr
(bphy_err/brcmf_dev_coredump) before reaching the arming gate.
The bus_reset work is shared across buses, so the drain is applied to
every remove path: PCIe (the .reset op introduced by the Fixes commit),
SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the
debugfs "reset" entry). cancel_work_sync() drains a running or pending
bus_reset work item before removal frees drvr, and patch 1/2 makes the
scratch-buffer release safe when reset teardown has already released
those DMA buffers.
This patch fixes the lifetime of the bus_reset work item itself. It does
not attempt to address the separate, pre-existing lifetime of the
asynchronous firmware completion started by the PCIe reset path. That
callback needs its own lifetime/ownership protocol and is being tracked
separately.
This issue was found by an in-house static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: reject free space cache with more entries than pages
When loading a v1 free space cache, __load_free_space_cache() takes
num_entries and num_bitmaps straight from the on-disk
btrfs_free_space_header. That header is stored in the tree_root under a key
with type 0, which the tree-checker has no case for, so neither count is
validated before the load trusts it.
The load loops num_entries times and maps the next page whenever the current
one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which
does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in
io_ctl_init() from the cache inode's i_size, not from num_entries:
num_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);
io_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS);
So if num_entries claims more records than the pages can hold, io_ctl->index
runs off the end of pages[]. The write side never hits this because
io_ctl_add_entry() and io_ctl_add_bitmap() both stop once
io_ctl->index >= io_ctl->num_pages; the read side just never had the same
check.
To trigger it, take a clean cache (num_entries = <N> here), set num_entries
in the header to 0x10000, and fix up the leaf checksum so it still passes
the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and
pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read
65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the
array:
BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565)
Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58
io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565)
__load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820)
load_free_space_cache (fs/btrfs/free-space-cache.c:1017)
caching_thread (fs/btrfs/block-group.c:880)
btrfs_work_helper (fs/btrfs/async-thread.c:312)
process_one_work
worker_thread
kthread
ret_from_fork
free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc()
at line 565, which is why that is the frame KASAN names. The out-of-bounds
slot is then treated as a struct page and handed to crc32c(), so the bad
read turns into a GP fault.
Add the missing check to io_ctl_check_crc(), which is where both the entry
loop and the bitmap loop end up. When num_entries is too large the load now
fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds
the free space from the extent tree, so a valid cache is never rejected. |
| In the Linux kernel, the following vulnerability has been resolved:
net, bpf: check master for NULL in xdp_master_redirect()
xdp_master_redirect() dereferences the result of
netdev_master_upper_dev_get_rcu() without a NULL check, but that helper
returns NULL when the receiving device has no upper-master adjacency.
The reach guard only checks netif_is_bond_slave(). On bond slave release
bond_upper_dev_unlink() drops the upper-master adjacency before clearing
IFF_SLAVE, so an XDP_TX reaching xdp_master_redirect() in that window
still passes netif_is_bond_slave() while master is already NULL, and
faults on master->flags at offset 0xb0:
BUG: kernel NULL pointer dereference, address: 00000000000000b0
RIP: 0010:xdp_master_redirect (net/core/filter.c:4432)
Call Trace:
xdp_master_redirect (net/core/filter.c:4432)
bpf_prog_run_generic_xdp (include/net/xdp.h:700)
do_xdp_generic (net/core/dev.c:5608)
__netif_receive_skb_one_core (net/core/dev.c:6204)
process_backlog (net/core/dev.c:6319)
__napi_poll (net/core/dev.c:7729)
net_rx_action (net/core/dev.c:7792)
handle_softirqs (kernel/softirq.c:622)
__dev_queue_xmit (include/linux/bottom_half.h:33)
packet_sendmsg (net/packet/af_packet.c:3082)
__sys_sendto (net/socket.c:2252)
Kernel panic - not syncing: Fatal exception in interrupt
The missing check dates back to the original code; commit 1921f91298d1
("net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master")
later added the master->flags read where the fault now lands but kept the
unconditional deref. Check master for NULL before use; a NULL master is
treated the same as one that is not up. |
| In the Linux kernel, the following vulnerability has been resolved:
usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()
genelink_rx_fixup() splits an aggregated RX frame into its individual
packets, using a per-packet length taken from device-supplied data. That
length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared
against how many bytes were actually received.
A malicious GeneLink (GL620A) device can therefore send a short URB whose
header claims packet_count > 1 and a first packet of up to 1514 bytes.
skb_put_data(gl_skb, packet->packet_data, size);
then copies past the end of the receive buffer and hands the adjacent slab
contents up the network stack, an out-of-bounds read that leaks kernel heap.
No privilege is required: the path runs in the usbnet RX softirq as soon as
the interface is up.
BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112)
Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14
Call Trace:
...
__asan_memcpy (mm/kasan/shadow.c:105)
genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112)
usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589)
process_one_work (kernel/workqueue.c:3322)
bh_worker (kernel/workqueue.c:3405)
tasklet_action (kernel/softirq.c:965)
handle_softirqs (kernel/softirq.c:622)
run_ksoftirqd (kernel/softirq.c:1076)
...
skb_pull() already verifies that the requested length fits the buffer and
returns NULL otherwise. Move it ahead of the copy and check its result, so
a packet that overruns the received data is rejected before it is read.
Well-formed frames, whose packets are fully present, are unaffected. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop
The loop in is_ap_in_tkip() iterates over IEs without verifying that
enough bytes remain before dereferencing the IE header or its payload:
- pIE->element_id and pIE->length are read without checking that
i + sizeof(*pIE) <= ie_length, so a truncated IE at the end of the
buffer causes an OOB read.
- For WLAN_EID_VENDOR_SPECIFIC the code compares pIE->data + 12,
which requires pIE->length >= 16. For WLAN_EID_RSN it compares
pIE->data + 8, requiring pIE->length >= 12. Neither requirement
is checked.
Add the missing IE header and payload bounds checks and guard each
data access with an explicit pIE->length minimum, matching the
pattern established in update_beacon_info(). |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate lcns_follow in log_replay conversion
log_replay() converts DIR_PAGE_ENTRY_32 records into DIR_PAGE_ENTRY
records when replaying version 0 restart tables.
During this conversion, the memmove() length is derived directly from
the on-disk lcns_follow field:
memmove(&dp->vcn, &dp0->vcn_low,
2 * sizeof(u64) +
le32_to_cpu(dp->lcns_follow) * sizeof(u64));
check_rstbl() validates restart table structure, but does not constrain
per-entry lcns_follow values relative to the entry size. A malformed
filesystem image can provide an oversized lcns_follow value, causing
the conversion memmove() to access memory beyond the bounds of the
allocated restart table buffer.
The same field is later used to bound iteration over page_lcns[],
so validating lcns_follow during conversion also prevents downstream
out-of-bounds access from the same malformed metadata.
Compute the maximum valid lcns_follow from the already-validated
restart table entry size and reject entries that exceed this bound.
Reuse the existing t16/t32 scratch variables already declared in
log_replay() to avoid introducing new declarations.
[almaz.alexandrovich@paragon-software.com: fixed the conflicts] |
| In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Release the VGA arbiter client on register_device() failure
The re-order in the Fixes commit below displaced vfio_pci_vga_init() as
the last failure point of what is now vfio_pci_core_register_device()
without introducing an unwind for the VGA arbiter registration.
In current kernels this is mostly benign because vfio_pci_set_decode()
only uses pci_dev state, but the original failure path could leave a
callback with a freed vdev cookie. The stale registration also becomes
unsafe again once the callback follows drvdata to the vfio device.
Add the required VGA unwind callout. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpci_rt1711h: unregister TCPCI port with devres
rt1711h_probe() registers the TCPCI port before requesting the interrupt
and enabling alert interrupts. If either of those later steps fails, the
probe function returns without unregistering the TCPCI port. The explicit
unregister currently only happens from the remove callback.
Register a devres action immediately after tcpci_register_port() succeeds,
so tcpci_unregister_port() runs on later probe failures and on driver
detach. Drop the remove callback to avoid unregistering the same port
twice.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code. |
| In the Linux kernel, the following vulnerability has been resolved:
hwrng: virtio: clamp device-reported used.len at copy_data()
random_recv_done() stores the device-reported used.len directly into
vi->data_avail. copy_data() then indexes vi->data[] using
vi->data_idx (advanced by previous copy_data() calls) and issues a
memcpy() without re-validating either value against the posted
buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32
or 64).
A malicious or buggy virtio-rng backend can set used.len beyond
sizeof(vi->data), steering the memcpy() past the end of the inline
array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes
those bytes into the guest RNG, and guest root can also observe
them directly via /dev/hwrng.
Concrete impact is inside the guest:
- Memory-safety / hardening: any virtio-rng backend that
over-reports used.len causes the driver to read past vi->data
into unrelated slab contents. hwrng_fillfn() is a kernel thread
that runs as soon as the device is probed; no guest userspace
interaction is required to first-trigger the OOB.
- Cross-boundary leak (confidential-compute threat model): a
malicious hypervisor cooperating with a malicious or compromised
guest root userspace can use /dev/hwrng as a leak channel for
guest-kernel heap data. The host sets a large used.len, guest
root reads /dev/hwrng, and the returned bytes contain guest
kernel slab contents that were adjacent to vi->data. In
practice, confidential-compute guests (SEV-SNP, TDX) usually
disable virtio-rng entirely, so this path is narrow, but the
fix is still worth carrying because the underlying
memory-safety bug contaminates the guest RNG on any host.
KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend
has been patched to report used.len = 0x10000:
BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0
Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52
Call Trace:
__asan_memcpy+0x23/0x60
virtio_read+0x394/0x5d0
hwrng_fillfn+0xb2/0x470
kthread+0x2cc/0x3a0
Allocated by task 1:
probe_common+0xa5/0x660
virtio_dev_probe+0x549/0xbc0
The buggy address belongs to the object at ffff88800ae0b800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 0 bytes to the right of
allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)
Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer
overflow in USB transport layer"), which hardened
usb9pfs_rx_complete() against unchecked device-reported length in
the USB 9p transport.
With the clamp at point of use and array_index_nospec() in place,
the same harness boots cleanly: copy_data() returns zero for the
bogus report, the device-supplied bytes after data_idx are
discarded, and the driver issues a fresh request. |
| In the Linux kernel, the following vulnerability has been resolved:
6lowpan: fix NHC entry use-after-free on error path
lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding
lowpan_nhc_lock. If the descriptor has no uncompress callback, the error
path drops the lock before printing nhc->name.
lowpan_nhc_del() removes descriptors under the same lock and then relies
on synchronize_net() before the owning module can be unloaded. That only
waits for net RX RCU readers. lowpan_header_decompress() is also exported
and can be reached from callers that are not necessarily covered by the net
core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive
path.
This leaves a race where one task drops lowpan_nhc_lock in the error path,
another task unregisters and frees the matching descriptor after
synchronize_net() returns, and the first task then dereferences nhc->name
for the warning.
With the post-unlock window widened, KASAN reports:
BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220
Read of size 8
lowpan_nhc_do_uncompression
lowpan_header_decompress
Fix this by printing the warning before dropping lowpan_nhc_lock, so the
descriptor name is read while unregister is still excluded. The malformed
packet is still rejected with -ENOTSUPP. |
| In the Linux kernel, the following vulnerability has been resolved:
tipc: fix out-of-bounds read in broadcast Gap ACK blocks
A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its
data area. tipc_get_gap_ack_blks() only verifies that the record's len
field is self-consistent with its ugack_cnt/bgack_cnt counts
(sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check
that the record actually fits in the message data area, msg_data_sz().
The unicast caller tipc_link_proto_rcv() bounds it ("if (glen > dlen)
break;"), but the broadcast caller tipc_bcast_sync_rcv() discards the
returned size, so tipc_link_advance_transmq() copies the record off the
receive skb with an attacker-controlled count:
this_ga = kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt),
GFP_ATOMIC);
A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one
ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its
data area is short, carrying a Gap ACK record with len = 0x400,
bgack_cnt = 0xff and ugack_cnt = 0. len then equals
struct_size(p, gacks, 255), so the consistency check passes and ga is
non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out
of the much smaller skb:
BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60
Read of size 1024 at addr ffff0000c7030d38 by task poc864/69
Call trace:
kmemdup_noprof+0x48/0x60
tipc_link_advance_transmq+0x86c/0xb80
tipc_link_bc_ack_rcv+0x19c/0x1e0
tipc_bcast_sync_rcv+0x1c4/0x2c4
tipc_rcv+0x85c/0x1340
tipc_l2_rcv_msg+0xac/0x104
The buggy address belongs to the object at ffff0000c7030d00
which belongs to the cache skbuff_small_head of size 704
The buggy address is located 56 bytes inside of
allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0)
The copied-out bytes are subsequently consumed as gap/ack values, but
the read is already out of bounds at the kmemdup() regardless of how
they are used.
The unicast STATE path drops such a message: "if (glen > dlen) break;"
skips the rest of STATE_MSG handling and the skb is freed. Make the
broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record
against msg_data_sz() and, when it does not fit, reports it back through
tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than
processed. ga is not cleared on this path: ga == NULL already means
"legacy peer without Selective ACK", a distinct legitimate state. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: restrict implied bcc[0] exemption to responses without data area
smb2_check_message() has a long-standing quirk that accepts a response
whose calculated length is one byte larger than the bytes actually
received ("server can return one byte more due to implied bcc[0]").
This was introduced to accommodate servers that omit the trailing bcc[0]
overlap byte when no data area is present.
However, the exemption is applied unconditionally, regardless of whether
the command actually carries a data area (has_smb2_data_area[]). When a
response with a data area is subject to the +1 exemption, the reported
data can extend one byte beyond the bytes actually received, yet
smb2_check_message() still accepts it. The subsequent decoder then reads
past the end of the receive buffer. This is reachable during NEGOTIATE
and SESSION_SETUP, before the session is established.
The resulting out-of-bounds reads are visible under KASAN when mounting
against a non-conforming server; both the SPNEGO/negTokenInit and the
NTLMSSP challenge decoders are affected:
BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x16a7/0x1b00
Read of size 1 at addr ffff8880084d67c0 by task mount.cifs/81
CPU: 1 UID: 0 PID: 81 Comm: mount.cifs Not tainted 7.1.0-rc6 #1
Call Trace:
<TASK>
dump_stack_lvl+0x4e/0x70
print_report+0x157/0x4c9
kasan_report+0xce/0x100
asn1_ber_decoder+0x16a7/0x1b00
decode_negTokenInit+0x19/0x30
SMB2_negotiate+0x31d9/0x4c90
cifs_negotiate_protocol+0x1f2/0x3f0
cifs_get_smb_ses+0x93f/0x17e0
cifs_mount_get_session+0x7f/0x3a0
cifs_mount+0xb4/0xcf0
cifs_smb3_do_mount+0x23a/0x1500
smb3_get_tree+0x3b0/0x630
vfs_get_tree+0x82/0x2d0
fc_mount+0x10/0x1b0
path_mount+0x50d/0x1de0
__x64_sys_mount+0x20b/0x270
do_syscall_64+0xee/0x590
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
Allocated by task 85:
kmem_cache_alloc_noprof+0x106/0x380
mempool_alloc_noprof+0x116/0x1e0
cifs_small_buf_get+0x31/0x80
allocate_buffers+0x10d/0x2b0
cifs_demultiplex_thread+0x1d5/0x1d50
kthread+0x2c6/0x390
ret_from_fork+0x36e/0x5a0
ret_from_fork_asm+0x1a/0x30
The buggy address is located 0 bytes to the right of
allocated 448-byte region [ffff8880084d6600, ffff8880084d67c0)
which belongs to the cache cifs_small_rq of size 448
BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x36/0x50
Read of size 329 at addr ffff88800726c678 by task mount.cifs/89
CPU: 0 UID: 0 PID: 89 Comm: mount.cifs Tainted: G B 7.1.0-rc6 #1
Call Trace:
<TASK>
dump_stack_lvl+0x4e/0x70
print_report+0x157/0x4c9
kasan_report+0xce/0x100
kasan_check_range+0x10f/0x1e0
__asan_memcpy+0x23/0x60
kmemdup_noprof+0x36/0x50
decode_ntlmssp_challenge+0x457/0x680
SMB2_sess_auth_rawntlmssp_negotiate+0x6f0/0xcb0
SMB2_sess_setup+0x219/0x4f0
cifs_setup_session+0x248/0xaf0
cifs_get_smb_ses+0xf79/0x17e0
cifs_mount_get_session+0x7f/0x3a0
cifs_mount+0xb4/0xcf0
cifs_smb3_do_mount+0x23a/0x1500
smb3_get_tree+0x3b0/0x630
vfs_get_tree+0x82/0x2d0
fc_mount+0x10/0x1b0
path_mount+0x50d/0x1de0
__x64_sys_mount+0x20b/0x270
do_syscall_64+0xee/0x590
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
Allocated by task 93:
kmem_cache_alloc_noprof+0x106/0x380
mempool_alloc_noprof+0x116/0x1e0
cifs_small_buf_get+0x31/0x80
allocate_buffers+0x10d/0x2b0
cifs_demultiplex_thread+0x1d5/0x1d50
kthread+0x2c6/0x390
ret_from_fork+0x36e/0x5a0
ret_from_fork_asm+0x1a/0x30
The buggy address is located 120 bytes inside of
allocated 448-byte region [ffff88800726c600, ffff88800726c7c0)
which belongs to the cache cifs_small_rq of size 448
Restrict the +1 exemption to responses that have no data area, so that
it still covers the bcc[0] omission it was meant for. When a data area
is present, the +1 discrepancy instead means the reported data length
overruns the
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()
OnAuth() has two bugs in the shared-key authentication path.
When the Privacy bit is set, rtw_wep_decrypt() is called without
verifying that the frame is long enough to contain a valid WEP IV and
ICV. Inside rtw_wep_decrypt(), length is computed as:
length = len - WLAN_HDR_A3_LEN - iv_len
and then passed as (length - 4) to crc32_le(). If len is less than
WLAN_HDR_A3_LEN + iv_len + icv_len (32 bytes), length - 4 is negative
and, after the implicit cast to size_t, causes crc32_le() to read far
beyond the frame buffer. Add a minimum length check before accessing
the IV field and calling the decryption path.
When processing a seq=3 response, rtw_get_ie() stores the Challenge
Text IE length in ie_len, but the subsequent memcmp() always reads 128
bytes regardless of ie_len. IEEE 802.11 mandates a challenge text of
exactly 128 bytes; reject any IE whose length field differs, matching
the check already applied to OnAuthClient(). |
