| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: amlogic - avoid double cleanup in meson_crypto_probe()
When meson_allocate_chanlist() fails after a partial allocation, it already
unwinds the allocated chanlist state through its local error path.
meson_crypto_probe() then jump to error_flow and calls
meson_free_chanlist() again, causing the same per-flow resources to be torn
down twice. In the reproduced failure path, the second teardown
re-entered crypto_engine_exit() on an already destroyed worker and KASAN
reported a slab-use-after-free in kthread_destroy_worker().
Prevent double-free by handling partial allocation failures locally within
meson_allocate_chanlist() and skipping the outer cleanup path.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available.
The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1,
using the reproducer under tools/testing/meson_crypto_probe. The reproducer
forces the second dma_alloc_attrs() call in the gxl-crypto probe path to
return NULL, making meson_allocate_chanlist() fail after partial
initialization. On the unpatched kernel this reliably triggered a
slab-use-after-free. With this fix applied, the same reproducer no longer
emits any KASAN report and the probe fails cleanly with -ENOMEM.
==================================================================
BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0
Read of size 8 at addr ff1100010c057a68 by task insmod/265
CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy)
Tainted: [O]=OOT_MODULE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x68/0xa0
print_report+0xcb/0x5e0
? __virt_addr_valid+0x21d/0x3f0
? kthread_destroy_worker+0xb2/0xd0
? kthread_destroy_worker+0xb2/0xd0
kasan_report+0xca/0x100
? kthread_destroy_worker+0xb2/0xd0
kthread_destroy_worker+0xb2/0xd0
meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto]
platform_probe+0x99/0x140
really_probe+0x1c6/0x6a0
? __pfx___device_attach_driver+0x10/0x10
__driver_probe_device+0x248/0x310
? acpi_driver_match_device+0xb0/0x100
driver_probe_device+0x48/0x210
? __pfx___device_attach_driver+0x10/0x10
__device_attach_driver+0x160/0x320
bus_for_each_drv+0x104/0x190
? __pfx_bus_for_each_drv+0x10/0x10
? _raw_spin_unlock_irqrestore+0x2c/0x50
__device_attach+0x19d/0x3b0
? __pfx___device_attach+0x10/0x10
? do_raw_spin_unlock+0x53/0x220
device_initial_probe+0x78/0xa0
bus_probe_device+0x5b/0x130
device_add+0xcfd/0x1430
? __pfx_device_add+0x10/0x10
? insert_resource+0x34/0x50
? lock_release+0xc9/0x290
platform_device_add+0x24e/0x590
? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro]
meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro]
do_one_initcall+0xc0/0x450
? __pfx_do_one_initcall+0x10/0x10
? _raw_spin_unlock_irqrestore+0x2c/0x50
? __create_object+0x59/0x80
? kasan_unpoison+0x27/0x60
do_init_module+0x27b/0x7d0
? __pfx_do_init_module+0x10/0x10
? kasan_quarantine_put+0x84/0x1d0
? kfree+0x32c/0x510
? load_module+0x561e/0x5ff0
load_module+0x54fe/0x5ff0
? __pfx_load_module+0x10/0x10
? security_file_permission+0x20/0x40
? kernel_read_file+0x23d/0x6e0
? mmap_region+0x235/0x4a0
? __pfx_kernel_read_file+0x10/0x10
? __file_has_perm+0x2c0/0x3e0
init_module_from_file+0x158/0x180
? __pfx_init_module_from_file+0x10/0x10
? __lock_acquire+0x45a/0x1ba0
? idempotent_init_module+0x315/0x610
? lock_release+0xc9/0x290
? lock
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
libfs: set SB_I_NOEXEC and SB_I_NODEV by default in init_pseudo()
Since commit 1e7ab6f67824 ("anon_inode: rework assertions"),
path_noexec() warns when an anonymous-inode file is mmap'd from a
superblock that has not set SB_I_NOEXEC. dma-buf backs its files this
way and never set the flag, so mmap of any exported buffer trips the
warning on a CONFIG_DEBUG_VFS=y kernel:
WARNING: CPU: 11 PID: 121813 at fs/exec.c:118 path_noexec+0x47/0x50
do_mmap+0x2b5/0x680
vm_mmap_pgoff+0x129/0x210
ksys_mmap_pgoff+0x177/0x240
__x64_sys_mmap+0x33/0x70
init_pseudo() sets up internal SB_NOUSER mounts that are never
path-reachable. Set both flags here so every pseudo filesystem gets
them by default instead of each caller setting them.
SB_I_NODEV is inert for unreachable mounts. SB_I_NOEXEC has one
visible effect: an executable mapping of a pseudo-fs fd, such as a
dma-buf, now fails with -EPERM, which is the invariant the assertion
enforces. No in-tree caller maps these executable.
Reproduce on CONFIG_DEBUG_VFS=y:
make -C tools/testing/selftests/dmabuf-heaps
sudo ./tools/testing/selftests/dmabuf-heaps/dmabuf-heap -t system |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: core: fix NULL-deref on adapter registration failure
If adapter registration ever fails the release callback would trigger a
NULL-pointer dereference as the completion struct has not been
initialised.
Note that before the offending commit this would instead have resulted
in a minor memory leak of the adapter name. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_midi: cancel pending IN work before freeing the midi object
The f_midi driver embeds a work item (midi->work) whose handler,
f_midi_in_work(), dereferences the enclosing struct f_midi through
container_of(). This work is armed from two sites: f_midi_complete(),
on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA
rawmidi output-stream start.
Neither f_midi_disable() nor f_midi_unbind() cancels midi->work.
f_midi_disable() only disables the endpoints and drains the in_req_fifo;
it does not synchronize the work item, and the sound card is released
asynchronously to the final free of the midi object.
The midi object is reference-counted (midi->free_ref) and is freed in
f_midi_free() only once both the usb_function reference and the rawmidi
private_data reference have been dropped. In f_midi_unbind(),
f_midi_disable() runs before the sound card is released, so while the
USB endpoints are already disabled the rawmidi device is still usable by
an open substream. A concurrent userspace write on such a substream can
reach f_midi_in_trigger() and queue midi->work again after
f_midi_disable() has returned. A work item armed this way may still be
pending when the last reference drops and f_midi_free() proceeds to
kfree(midi), letting f_midi_in_work() dereference the struct after it
has been freed, a use-after-free.
For this reason cancelling midi->work in f_midi_disable() would not be
sufficient: the ALSA trigger path can rearm the work after disable()
returns. Cancelling at the refcount-zero free site is the boundary
after which neither arming source can survive, because by then both
references that keep the midi object alive have been dropped: the USB
endpoints are already disabled and the rawmidi device has been released.
Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero
block of f_midi_free(), before the embedded work_struct is freed along
with the rest of the structure. opts->lock is a sleeping mutex, so
calling cancel_work_sync() under it is permitted, and the handler takes
midi->transmit_lock rather than opts->lock, so no self-deadlock can
occur while it waits for a running instance of the work to finish.
This issue was found by an in-house static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown
The Broadcom BDC UDC driver registers its IRQ handler with
devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm
only after bdc_remove() returns. devm releases resources in reverse
LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() ->
bdc_mem_free() manually before returning: bdc_udc_exit() tears down
individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() ->
bdc_mem_free() frees and NULLs the DMA-coherent status-report ring
(bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while
the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED)
remains deliverable in the window up to the post-remove devm
free_irq().
On receipt of a shared interrupt in that window, bdc_udc_interrupt()
dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA)
and dispatches sr_handler callbacks that index into bdc_ep_array,
causing a NULL-deref or use-after-free.
The same window affects the delayed_work bdc->func_wake_notify, which is
armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change()
-> schedule_delayed_work() and may self-rearm from its own callback
bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a
queued work item that fires after bdc_remove() returns and the bdc
structure is devm-freed dereferences freed memory.
Replace devm_request_irq() with request_irq() and add an explicit
free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before
free_irq() to stop the device from asserting interrupts, then
free_irq() drains any in-flight handler, then cancel_delayed_work_sync()
drains the func_wake_notify delayed work. This ordering ensures the
IRQ handler and delayed work cannot interfere with the subsequent
endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the
matching free_irq() into the bdc_udc_init() error path so the IRQ is
released on probe failure, and route the bdc_init_ep() failure through
err0 instead of returning directly.
This issue was found by an in-house static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix a use-after-free problem in rxe_mmap
rxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list
and releases pending_lock while the struct's kref is still at 1:
list_del_init(&ip->pending_mmaps);
spin_unlock_bh(&rxe->pending_lock); /* ref == 1, no lock held */
ret = remap_vmalloc_range(vma, ip->obj, 0); /* walks PTEs */
[...]
rxe_vma_open(vma); /* kref_get, ref → 2 */
remap_vmalloc_range_partial() walks PTEs without any lock.
A concurrent DESTROY_CQ ioctl on another CPU calls:
kref_put(&q->ip->ref, rxe_mmap_release) /* ref 1→0 */
vfree(ip->obj) /* clears vmalloc PTEs mid-walk */
kfree(ip) /* frees rxe_mmap_info */
This yields:
1. Kernel crash, vmalloc_to_page() returns NULL when vfree wins the
per-PTE race -> vm_insert_page(NULL) → GPF in validate_page_before_insert
2. Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears
it. User VMA holds a PTE to a free'd page which might eventually get
reallocated later by vmalloc which allows the attacker to get a clean
page-level UAF.
It is worth noting that even though a page-level UAF is possible given
the strong primitive, it is statistically very difficult to achieve
given the very short time window (after the last insert_page and before
the kref_get).
The call trace are as below:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 UID: 1000 PID: 413 Comm: poc Not tainted 7.0.0-rc5-dirty #28 PREEMPT(lazy)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:validate_page_before_insert+0x32/0x300
Code: e5 41 57 41 56 49 89 fe 41 55 41 54 53 48 89 f3 e8 93 b5 a3 ff 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7b 02 00 00 4c 8b 63 08 31 ff 4d 89 e5 41 83 e5
RSP: 0018:ffff88811b15f2f0 EFLAGS: 00000202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008
RBP: ffff88811b15f318 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881181eee00
R13: 0000000000000000 R14: ffff8881181eee00 R15: ffff8881181eee20
FS: 00007b1e000f76c0(0000) GS:ffff8884268e0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007b1e00a24ac0 CR3: 0000000116eb3000 CR4: 00000000000006f0
Call Trace:
<TASK>
insert_page+0x8f/0x190
? __pfx_insert_page+0x10/0x10
? kasan_save_alloc_info+0x38/0x60
vm_insert_page+0x2e7/0x400
remap_vmalloc_range_partial+0x212/0x3e0
remap_vmalloc_range+0x6e/0xb0
? __kasan_check_write+0x14/0x30
rxe_mmap+0x2e9/0x5d0
ib_uverbs_mmap+0x1ad/0x2c0
__mmap_region+0x12c2/0x2ad0
? __pfx___mmap_region+0x10/0x10
? __sanitizer_cov_trace_switch+0x58/0xb0
? mas_prev_slot+0x360/0x39c0
? __sanitizer_cov_trace_switch+0x58/0xb0
? mas_next_slot+0x1e5b/0x2f40
? __sanitizer_cov_trace_cmp8+0x18/0x30
? unmapped_area_topdown+0x4dd/0x610
? kfree+0x1b1/0x440
? free_cpumask_var+0x16/0x30
? __kasan_slab_free+0x7d/0xa0
? __sanitizer_cov_trace_cmp8+0x18/0x30
mmap_region+0x2e6/0x3c0
do_mmap+0xa3e/0x12a0
? __pfx_do_mmap+0x10/0x10
? __kasan_check_write+0x14/0x30
? down_write_killable+0xba/0x160
? __pfx_down_write_killable+0x10/0x10
? __sanitizer_cov_trace_cmp4+0x16/0x30
vm_mmap_pgoff+0x2d4/0x4a0
? __pfx_vm_mmap_pgoff+0x10/0x10
? fget+0x1bf/0x270
ksys_mmap_pgoff+0x40c/0x690
? __sanitizer_cov_trace_const_cmp4+0x16/0x30
? __pfx_ksys_mmap_pgoff+0x10/0x10
? __kasan_check_write+0x14/0x30
? _raw_spin_trylock+0xbb/0x130
? __pfx__raw_spin_trylock+0x10/0x10
__x64_sys_mmap+0x135/0x1e0
x64_sys_c
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT
In PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible
context. bpf_mem_alloc must be used in PREEMPT_RT. This patch is
to enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT
is enabled.
[ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
[ 35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs
[ 35.118569] preempt_count: 1, expected: 0
[ 35.118571] RCU nest depth: 1, expected: 1
[ 35.118577] INFO: lockdep is turned off.
...
[ 35.118647] __might_resched+0x433/0x5b0
[ 35.118677] rt_spin_lock+0xc3/0x290
[ 35.118700] ___slab_alloc+0x72/0xc40
[ 35.118723] __kmalloc_noprof+0x13f/0x4e0
[ 35.118732] bpf_map_kzalloc+0xe5/0x220
[ 35.118740] bpf_selem_alloc+0x1d2/0x7b0
[ 35.118755] bpf_local_storage_update+0x2fa/0x8b0
[ 35.118784] bpf_sk_storage_get_tracing+0x15a/0x1d0
[ 35.118791] bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66
[ 35.118795] bpf_trace_run3+0x222/0x400
[ 35.118820] __bpf_trace_inet_sock_set_state+0x11/0x20
[ 35.118824] trace_inet_sock_set_state+0x112/0x130
[ 35.118830] inet_sk_state_store+0x41/0x90
[ 35.118836] tcp_set_state+0x3b3/0x640
There is no need to adjust the gfp_flags passing to the
bpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL.
The verifier has ensured GFP_KERNEL is passed only in sleepable context.
It has been an old issue since the first introduction of the
bpf_local_storage ~5 years ago, so this patch targets the bpf-next.
bpf_mem_alloc is needed to solve it, so the Fixes tag is set
to the commit when bpf_mem_alloc was first used in the bpf_local_storage. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate compound request size before reading StructureSize2
When ksmbd validates a compound (chained) SMB2 request,
ksmbd_smb2_check_message() reads pdu->StructureSize2 without first
checking that the compound element is large enough to contain it.
StructureSize2 is a 2-byte field at offset 64
(__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element.
The compound-walking logic only guarantees that a full 64-byte SMB2
header is present for the trailing element: when NextCommand is 0, len is
reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A
remote client can craft a compound request whose last element has exactly
64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte
past the receive buffer, producing a slab-out-of-bounds read.
BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402)
Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14
The buggy address is located 172 bytes inside of allocated 173-byte region
Workqueue: ksmbd-io handle_ksmbd_work
Call Trace:
...
kasan_report (mm/kasan/report.c:595)
ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402)
handle_ksmbd_work (fs/smb/server/server.c:119)
process_one_work (kernel/workqueue.c:3314)
worker_thread (kernel/workqueue.c:3397)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
Reject any compound element that is too small to hold StructureSize2
before dereferencing it. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/mremap: fix address wraparound in move_page_tables()
On 32-bit platforms, it is possible for the expression `len + old_addr <
old_end` to be false-positive if `len + old_addr` wraps around.
`old_addr` is the cursor in the old range up to which page table entries
have been moved; so if the operation succeeded, `old_addr` is the *end* of
the old region, and adding `len` to it can wrap.
The overflow causes mremap() to mistakenly believe that PTEs have been
copied; the consequence is that mremap() bails out, but doesn't move the
PTEs back before the new VMA is unmapped, causing anonymous pages in the
region to be lost. So basically if userspace tries to mremap() a
private-anon region and hits this bug, mremap() will return an error and
the private-anon region's contents appear to have been zeroed.
The idea of this check is that `old_end - len` is the original start
address, and writing the check that way also makes it easier to read; so
fix the check by rearranging the comparison accordingly.
(An alternate fix would be to refactor this function by introducing an
"orig_old_start" variable or such.)
Tested in a VM with a 32-bit X86 kernel; without the patch:
```
user@horn:~/big_mremap$ cat test.c
#define _GNU_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <err.h>
#include <sys/mman.h>
#define ADDR1 ((void*)0x60000000)
#define ADDR2 ((void*)0x10000000)
#define SIZE 0x50000000uL
int main(void) {
unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE,
MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0);
if (p1 == MAP_FAILED)
err(1, "mmap 1");
unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE,
MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0);
if (p2 == MAP_FAILED)
err(1, "mmap 2");
*p1 = 0x41;
printf("first char is 0x%02hhx\n", *p1);
unsigned char *p3 = mremap(p1, SIZE, SIZE,
MREMAP_MAYMOVE|MREMAP_FIXED, p2);
if (p3 == MAP_FAILED) {
printf("mremap() failed; first char is 0x%02hhx\n", *p1);
} else {
printf("mremap() succeeded; first char is 0x%02hhx\n", *p3);
}
}
user@horn:~/big_mremap$ gcc -static -o test test.c
user@horn:~/big_mremap$ setarch -R ./test
first char is 0x41
mremap() failed; first char is 0x00
```
With the patch:
```
user@horn:~/big_mremap$ setarch -R ./test
first char is 0x41
mremap() succeeded; first char is 0x41
``` |
| In the Linux kernel, the following vulnerability has been resolved:
nexthop: initialize extack in nh_res_bucket_migrate()
nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to
call_nexthop_res_bucket_notifiers(). When
nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns
-ENOMEM), the error is propagated back before any notifier sets
extack._msg, and the error path formats the stale pointer with
pr_err_ratelimited("%s\n", extack._msg). With CONFIG_INIT_STACK_NONE
this dereferences uninitialized stack memory:
Oops: general protection fault, probably for non-canonical address ...
KASAN: maybe wild-memory-access in range [...]
RIP: 0010:string (lib/vsprintf.c:730)
vsnprintf (lib/vsprintf.c:2945)
_printk (kernel/printk/printk.c:2504)
nh_res_bucket_migrate (net/ipv4/nexthop.c:1816)
nh_res_table_upkeep (net/ipv4/nexthop.c:1866)
rtm_new_nexthop (net/ipv4/nexthop.c:3323)
rtnetlink_rcv_msg (net/core/rtnetlink.c:7076)
netlink_sendmsg (net/netlink/af_netlink.c:1900)
Kernel panic - not syncing: Fatal exception
Zero-initialize extack so _msg is NULL on error paths that never set it. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: fix NVM tag length underflow in TLV parser
In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is
"while (idx < length - sizeof(struct tlv_type_nvm))". "length" is a signed
int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a
size_t (12), so "length" is converted to size_t and any firmware-supplied
"length" < 12 makes the subtraction wrap to a huge value. The loop body
then reads a 12-byte struct tlv_type_nvm past the end of the short
vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it).
Rewrite the bound as "idx + sizeof(struct tlv_type_nvm) <= length"; both
operands are non-negative, so it no longer underflows and a "length" too
small for one record correctly skips the loop.
BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421)
Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52
Workqueue: hci0 hci_power_on
Call Trace:
...
kasan_report (mm/kasan/report.c:595)
qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617)
qca_uart_setup (drivers/bluetooth/btqca.c:948)
qca_setup (drivers/bluetooth/hci_qca.c:2029)
hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438)
hci_dev_open_sync (net/bluetooth/hci_sync.c:5227)
hci_power_on (net/bluetooth/hci_core.c:920)
process_one_work (kernel/workqueue.c:3322)
worker_thread (kernel/workqueue.c:3486)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245) |
| In the Linux kernel, the following vulnerability has been resolved:
mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n
On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed
attribute table itself instead of calling ip_valid_fib_dump_req(). The
RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is
present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no
RTA_OIF hits a NULL dereference.
RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without
CAP_NET_ADMIN, so an unprivileged user can trigger it.
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189)
Call Trace:
mpls_dump_routes (net/mpls/af_mpls.c:2236)
netlink_dump (net/netlink/af_netlink.c:2331)
__netlink_dump_start (net/netlink/af_netlink.c:2446)
rtnetlink_rcv_msg (net/core/rtnetlink.c:7033)
netlink_rcv_skb (net/netlink/af_netlink.c:2556)
netlink_unicast (net/netlink/af_netlink.c:1345)
netlink_sendmsg (net/netlink/af_netlink.c:1900)
__sock_sendmsg (net/socket.c:790)
____sys_sendmsg (net/socket.c:2684)
___sys_sendmsg (net/socket.c:2738)
__sys_sendmsg (net/socket.c:2770)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Skip unset attributes, as ip_valid_fib_dump_req() does. |
| 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:
gtp: check skb_pull_data() return in gtp1u_send_echo_resp()
gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its
caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr +
gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For
a 16-19 byte echo request the pull fails and returns NULL without
advancing skb->data; execution continues, and the following skb_push()
plus the IP header pushed by iptunnel_xmit() move skb->data below
skb->head, tripping skb_under_panic().
Fix it by dropping the packet when skb_pull_data() fails.
skbuff: skb_under_panic: ...
kernel BUG at net/core/skbuff.c:214!
Call Trace:
skb_push (net/core/skbuff.c:2648)
iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82)
gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920)
udp_queue_rcv_one_skb (net/ipv4/udp.c:2388)
...
Kernel panic - not syncing: Fatal exception in interrupt |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix sk_dst_cache double-free in xfrm_user_policy()
xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(),
i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with
rcu_dereference_protected(), stores NULL and dst_release()s the old dst.
That is only safe if no other thread modifies sk_dst_cache concurrently.
For a connected UDP socket that does not hold: the transmit fast path
(udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly
with an atomic xchg(). A per-socket policy change racing a send can make
both sides observe the same old dst and each dst_release() it, dropping
the socket's single reference twice and freeing the xfrm_dst bundle while
it is still referenced:
BUG: KASAN: slab-use-after-free in dst_release
Write of size 4 at addr ffff88801897b6c0 by task exploit/155
Call Trace:
...
dst_release (... ./include/linux/rcuref.h:109)
xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053)
do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347)
ip_setsockopt (net/ipv4/ip_sockglue.c:1417)
do_sock_setsockopt (net/socket.c:2368)
__sys_setsockopt (net/socket.c:2393)
__x64_sys_setsockopt (net/socket.c:2396)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Reachable by an unprivileged user via a user+network namespace.
Use the atomic sk_dst_reset() so the cache is cleared and released with a
single xchg(): whichever side wins releases the dst once, the other sees
NULL and does nothing. Behaviour is otherwise unchanged. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: p54: validate RX frame length in p54_rx_eeprom_readback()
p54_rx_eeprom_readback() copies the requested EEPROM slice out of a
device-supplied readback frame without checking that the skb actually holds
that many bytes. Commit da1b9a55ff11 ("wifi: p54: prevent buffer-overflow in
p54_rx_eeprom_readback()") closed the destination overflow by copying a
fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len),
but the source side is still unbounded: nothing verifies the frame is long
enough to supply that many bytes.
A malicious USB device can send a short frame whose advertised len matches
priv->eeprom_slice_size while the payload is truncated. The equality check
passes and memcpy() reads past the end of the skb, leaking adjacent heap:
BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507)
Read of size 1016 at addr ffff88800f077114 by task swapper/0/0
Call Trace:
<IRQ>
...
__asan_memcpy (mm/kasan/shadow.c:105)
p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507)
p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163)
__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657)
dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005)
...
</IRQ>
The buggy address belongs to the object at ffff88800f0770c0
which belongs to the cache skbuff_small_head of size 704
The buggy address is located 84 bytes inside of
allocated 704-byte region [ffff88800f0770c0, ffff88800f077380)
Check that the slice fits in the skb before copying. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure
ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old
template before allocating the replacement. If the kzalloc() then fails,
it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points
at the object already queued for freeing. A later update or AP teardown
re-queues that same rcu_head; the second free is caught by KASAN when the
RCU sheaf is processed in softirq:
BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850)
Free of addr ffff88800d06f300 by task exploit/145
...
__rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940)
rcu_free_sheaf (mm/slub.c:5850)
rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869)
handle_softirqs (kernel/softirq.c:622)
The buggy address belongs to the cache kmalloc-128 of size 128
Queue the old object for kfree_rcu() only after the new one is published,
matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon(). |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix fils_discovery double free on alloc failure
ieee80211_set_fils_discovery() calls kfree_rcu() on the old template
before allocating the replacement. If the kzalloc() then fails, it
returns -ENOMEM while link->u.ap.fils_discovery still points at the
object already queued for freeing. A later update or AP teardown
(ieee80211_stop_ap()) re-queues that same rcu_head; the second free is
caught by KASAN when the RCU sheaf is processed in softirq:
BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850)
Free of addr ffff88800c065280 by task swapper/0/0
...
__rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940)
rcu_free_sheaf (mm/slub.c:5850)
rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869)
handle_softirqs (kernel/softirq.c:622)
The buggy address belongs to the cache kmalloc-96 of size 96
Queue the old object for kfree_rcu() only after the new one is published,
matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon(). |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: tcp: fix double sock release on batch realloc
bpf_iter_tcp_batch() releases the current batch via
bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites
each slot with the socket cookie, then grows the batch. cur_sk/end_sk
are kept for bpf_iter_tcp_resume(), but on realloc failure the function
returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over
slots that now hold cookies rather than sock pointers.
bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and
dereferences a cookie as a struct sock.
Empty the batch on the failure path so stop() does not release it
again. The sockets were already freed by the first
bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans
the bucket from the start instead of skipping it. The sibling
GFP_NOWAIT failure path still holds real socket references and is left
for stop() to release.
BUG: KASAN: null-ptr-deref in __sock_gen_cookie
Read of size 8 at addr 0000000000000059 by task exploit
...
__sock_gen_cookie (net/core/sock_diag.c:28)
bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918)
bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270)
bpf_seq_read (kernel/bpf/bpf_iter.c:205)
vfs_read (fs/read_write.c:572)
ksys_read (fs/read_write.c:716)
do_syscall_64
entry_SYSCALL_64_after_hwframe
Kernel panic - not syncing: Fatal exception |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst()
On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst()
releases the device reference with netdev_put() but leaves
xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev)
again, so the same net_device reference is released twice, underflowing
its refcount (ref_tracker WARNING + "unregister_netdevice: waiting for
<dev> to become free").
Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM
device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in
net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error.
ref_tracker: reference already released.
ref_tracker: allocated in:
xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86)
...
udpv6_sendmsg (net/ipv6/udp.c:1696)
...
ref_tracker: freed in:
xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90)
...
WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780
dst_destroy (net/core/dst.c:115)
rcu_core
handle_softirqs
... |
