Security Vulnerabilities - CVEs Published In 2024
In the Linux kernel, the following vulnerability has been resolved:
binder: fix freeze UAF in binder_release_work()
When a binder reference is cleaned up, any freeze work queued in the
associated process should also be removed. Otherwise, the reference is
freed while its ref->freeze.work is still queued in proc->work leading
to a use-after-free issue as shown by the following KASAN report:
==================================================================
BUG: KASAN: slab-use-after-free in binder_release_work+0x398/0x3d0
Read of size 8 at addr ffff31600ee91488 by task kworker/5:1/211
CPU: 5 UID: 0 PID: 211 Comm: kworker/5:1 Not tainted 6.11.0-rc7-00382-gfc6c92196396 #22
Hardware name: linux,dummy-virt (DT)
Workqueue: events binder_deferred_func
Call trace:
binder_release_work+0x398/0x3d0
binder_deferred_func+0xb60/0x109c
process_one_work+0x51c/0xbd4
worker_thread+0x608/0xee8
Allocated by task 703:
__kmalloc_cache_noprof+0x130/0x280
binder_thread_write+0xdb4/0x42a0
binder_ioctl+0x18f0/0x25ac
__arm64_sys_ioctl+0x124/0x190
invoke_syscall+0x6c/0x254
Freed by task 211:
kfree+0xc4/0x230
binder_deferred_func+0xae8/0x109c
process_one_work+0x51c/0xbd4
worker_thread+0x608/0xee8
==================================================================
This commit fixes the issue by ensuring any queued freeze work is removed
when cleaning up a binder reference.
CVSS Score
7.8
EPSS Score
0.0
Published
2024-12-27
In the Linux kernel, the following vulnerability has been resolved:
binder: fix OOB in binder_add_freeze_work()
In binder_add_freeze_work() we iterate over the proc->nodes with the
proc->inner_lock held. However, this lock is temporarily dropped to
acquire the node->lock first (lock nesting order). This can race with
binder_deferred_release() which removes the nodes from the proc->nodes
rbtree and adds them into binder_dead_nodes list. This leads to a broken
iteration in binder_add_freeze_work() as rb_next() will use data from
binder_dead_nodes, triggering an out-of-bounds access:
==================================================================
BUG: KASAN: global-out-of-bounds in rb_next+0xfc/0x124
Read of size 8 at addr ffffcb84285f7170 by task freeze/660
CPU: 8 UID: 0 PID: 660 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #18
Hardware name: linux,dummy-virt (DT)
Call trace:
rb_next+0xfc/0x124
binder_add_freeze_work+0x344/0x534
binder_ioctl+0x1e70/0x25ac
__arm64_sys_ioctl+0x124/0x190
The buggy address belongs to the variable:
binder_dead_nodes+0x10/0x40
[...]
==================================================================
This is possible because proc->nodes (rbtree) and binder_dead_nodes
(list) share entries in binder_node through a union:
struct binder_node {
[...]
union {
struct rb_node rb_node;
struct hlist_node dead_node;
};
Fix the race by checking that the proc is still alive. If not, simply
break out of the iteration.
CVSS Score
7.1
EPSS Score
0.0
Published
2024-12-27
In the Linux kernel, the following vulnerability has been resolved:
binder: fix node UAF in binder_add_freeze_work()
In binder_add_freeze_work() we iterate over the proc->nodes with the
proc->inner_lock held. However, this lock is temporarily dropped in
order to acquire the node->lock first (lock nesting order). This can
race with binder_node_release() and trigger a use-after-free:
==================================================================
BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c
Write of size 4 at addr ffff53c04c29dd04 by task freeze/640
CPU: 5 UID: 0 PID: 640 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #17
Hardware name: linux,dummy-virt (DT)
Call trace:
_raw_spin_lock+0xe4/0x19c
binder_add_freeze_work+0x148/0x478
binder_ioctl+0x1e70/0x25ac
__arm64_sys_ioctl+0x124/0x190
Allocated by task 637:
__kmalloc_cache_noprof+0x12c/0x27c
binder_new_node+0x50/0x700
binder_transaction+0x35ac/0x6f74
binder_thread_write+0xfb8/0x42a0
binder_ioctl+0x18f0/0x25ac
__arm64_sys_ioctl+0x124/0x190
Freed by task 637:
kfree+0xf0/0x330
binder_thread_read+0x1e88/0x3a68
binder_ioctl+0x16d8/0x25ac
__arm64_sys_ioctl+0x124/0x190
==================================================================
Fix the race by taking a temporary reference on the node before
releasing the proc->inner lock. This ensures the node remains alive
while in use.
CVSS Score
7.0
EPSS Score
0.0
Published
2024-12-27
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer
The AD7923 was updated to support devices with 8 channels, but the size
of tx_buf and ring_xfer was not increased accordingly, leading to a
potential buffer overflow in ad7923_update_scan_mode().
CVSS Score
5.5
EPSS Score
0.0
Published
2024-12-27
In the Linux kernel, the following vulnerability has been resolved:
nfsd: make sure exp active before svc_export_show
The function `e_show` was called with protection from RCU. This only
ensures that `exp` will not be freed. Therefore, the reference count for
`exp` can drop to zero, which will trigger a refcount use-after-free
warning when `exp_get` is called. To resolve this issue, use
`cache_get_rcu` to ensure that `exp` remains active.
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 3 PID: 819 at lib/refcount.c:25
refcount_warn_saturate+0xb1/0x120
CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
RIP: 0010:refcount_warn_saturate+0xb1/0x120
...
Call Trace:
<TASK>
e_show+0x20b/0x230 [nfsd]
seq_read_iter+0x589/0x770
seq_read+0x1e5/0x270
vfs_read+0x125/0x530
ksys_read+0xc1/0x160
do_syscall_64+0x5f/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVSS Score
7.8
EPSS Score
0.0
Published
2024-12-27
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Fix PCI domain ID release in pci_epc_destroy()
pci_epc_destroy() invokes pci_bus_release_domain_nr() to release the PCI
domain ID, but there are two issues:
- 'epc->dev' is passed to pci_bus_release_domain_nr() which was already
freed by device_unregister(), leading to a use-after-free issue.
- Domain ID corresponds to the EPC device parent, so passing 'epc->dev'
is also wrong.
Fix these issues by passing 'epc->dev.parent' to
pci_bus_release_domain_nr() and also do it before device_unregister().
[mani: reworded subject and description]
CVSS Score
7.8
EPSS Score
0.0
Published
2024-12-27
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix usage slab after free
[ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147
[ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1
[ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
[ +0.000016] Call Trace:
[ +0.000008] <TASK>
[ +0.000009] dump_stack_lvl+0x76/0xa0
[ +0.000017] print_report+0xce/0x5f0
[ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[ +0.000019] ? srso_return_thunk+0x5/0x5f
[ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200
[ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[ +0.000019] kasan_report+0xbe/0x110
[ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[ +0.000023] __asan_report_load8_noabort+0x14/0x30
[ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[ +0.000020] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __kasan_check_write+0x14/0x30
[ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched]
[ +0.000020] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __kasan_check_write+0x14/0x30
[ +0.000013] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? enable_work+0x124/0x220
[ +0.000015] ? __pfx_enable_work+0x10/0x10
[ +0.000013] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? free_large_kmalloc+0x85/0xf0
[ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched]
[ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu]
[ +0.000735] ? __kasan_check_read+0x11/0x20
[ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu]
[ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu]
[ +0.000679] ? mutex_unlock+0x80/0xe0
[ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu]
[ +0.000662] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? __kasan_check_write+0x14/0x30
[ +0.000013] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? mutex_unlock+0x80/0xe0
[ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu]
[ +0.000663] drm_minor_release+0xc9/0x140 [drm]
[ +0.000081] drm_release+0x1fd/0x390 [drm]
[ +0.000082] __fput+0x36c/0xad0
[ +0.000018] __fput_sync+0x3c/0x50
[ +0.000014] __x64_sys_close+0x7d/0xe0
[ +0.000014] x64_sys_call+0x1bc6/0x2680
[ +0.000014] do_syscall_64+0x70/0x130
[ +0.000014] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190
[ +0.000015] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? irqentry_exit+0x43/0x50
[ +0.000012] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? exc_page_fault+0x7c/0x110
[ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ +0.000014] RIP: 0033:0x7ffff7b14f67
[ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff
[ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
[ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67
[ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003
[ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000
[ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8
[ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040
[ +0.000020] </TASK>
[ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:
[ +0.000014] kasan_save_stack+0x28/0x60
[ +0.000008] kasan_save_track+0x18/0x70
[ +0.000007] kasan_save_alloc_info+0x38/0x60
[ +0.000007] __kasan_kmalloc+0xc1/0xd0
[ +0.000007] kmalloc_trace_noprof+0x180/0x380
[ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched]
[ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu]
[ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu]
[ +0.000662] amdgpu_pci_p
---truncated---
CVSS Score
7.8
EPSS Score
0.0
Published
2024-12-27
In the Linux kernel, the following vulnerability has been resolved:
udmabuf: change folios array from kmalloc to kvmalloc
When PAGE_SIZE 4096, MAX_PAGE_ORDER 10, 64bit machine,
page_alloc only support 4MB.
If above this, trigger this warn and return NULL.
udmabuf can change size limit, if change it to 3072(3GB), and then alloc
3GB udmabuf, will fail create.
[ 4080.876581] ------------[ cut here ]------------
[ 4080.876843] WARNING: CPU: 3 PID: 2015 at mm/page_alloc.c:4556 __alloc_pages+0x2c8/0x350
[ 4080.878839] RIP: 0010:__alloc_pages+0x2c8/0x350
[ 4080.879470] Call Trace:
[ 4080.879473] <TASK>
[ 4080.879473] ? __alloc_pages+0x2c8/0x350
[ 4080.879475] ? __warn.cold+0x8e/0xe8
[ 4080.880647] ? __alloc_pages+0x2c8/0x350
[ 4080.880909] ? report_bug+0xff/0x140
[ 4080.881175] ? handle_bug+0x3c/0x80
[ 4080.881556] ? exc_invalid_op+0x17/0x70
[ 4080.881559] ? asm_exc_invalid_op+0x1a/0x20
[ 4080.882077] ? udmabuf_create+0x131/0x400
Because MAX_PAGE_ORDER, kmalloc can max alloc 4096 * (1 << 10), 4MB
memory, each array entry is pointer(8byte), so can save 524288 pages(2GB).
Further more, costly order(order 3) may not be guaranteed that it can be
applied for, due to fragmentation.
This patch change udmabuf array use kvmalloc_array, this can fallback
alloc into vmalloc, which can guarantee allocation for any size and does
not affect the performance of kmalloc allocations.
CVSS Score
5.5
EPSS Score
0.0
Published
2024-12-27
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: don't query the device logical block size multiple times
Devices block sizes may change. One of these cases is a loop device by
using ioctl LOOP_SET_BLOCK_SIZE.
While this may cause other issues like IO being rejected, in the case of
hfsplus, it will allocate a block by using that size and potentially write
out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the
latter function reads a different io_size.
Using a new min_io_size initally set to sb_min_blocksize works for the
purposes of the original fix, since it will be set to the max between
HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the
max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not
initialized.
Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024
and 4096.
The produced KASAN report before the fix looks like this:
[ 419.944641] ==================================================================
[ 419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a
[ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678
[ 419.947612]
[ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84
[ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[ 419.950035] Call Trace:
[ 419.950384] <TASK>
[ 419.950676] dump_stack_lvl+0x57/0x78
[ 419.951212] ? hfsplus_read_wrapper+0x659/0xa0a
[ 419.951830] print_report+0x14c/0x49e
[ 419.952361] ? __virt_addr_valid+0x267/0x278
[ 419.952979] ? kmem_cache_debug_flags+0xc/0x1d
[ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a
[ 419.954231] kasan_report+0x89/0xb0
[ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a
[ 419.955367] hfsplus_read_wrapper+0x659/0xa0a
[ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10
[ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9
[ 419.957214] ? _raw_spin_unlock+0x1a/0x2e
[ 419.957772] hfsplus_fill_super+0x348/0x1590
[ 419.958355] ? hlock_class+0x4c/0x109
[ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10
[ 419.959499] ? __pfx_string+0x10/0x10
[ 419.960006] ? lock_acquire+0x3e2/0x454
[ 419.960532] ? bdev_name.constprop.0+0xce/0x243
[ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10
[ 419.961799] ? pointer+0x3f0/0x62f
[ 419.962277] ? __pfx_pointer+0x10/0x10
[ 419.962761] ? vsnprintf+0x6c4/0xfba
[ 419.963178] ? __pfx_vsnprintf+0x10/0x10
[ 419.963621] ? setup_bdev_super+0x376/0x3b3
[ 419.964029] ? snprintf+0x9d/0xd2
[ 419.964344] ? __pfx_snprintf+0x10/0x10
[ 419.964675] ? lock_acquired+0x45c/0x5e9
[ 419.965016] ? set_blocksize+0x139/0x1c1
[ 419.965381] ? sb_set_blocksize+0x6d/0xae
[ 419.965742] ? __pfx_hfsplus_fill_super+0x10/0x10
[ 419.966179] mount_bdev+0x12f/0x1bf
[ 419.966512] ? __pfx_mount_bdev+0x10/0x10
[ 419.966886] ? vfs_parse_fs_string+0xce/0x111
[ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10
[ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10
[ 419.968073] legacy_get_tree+0x104/0x178
[ 419.968414] vfs_get_tree+0x86/0x296
[ 419.968751] path_mount+0xba3/0xd0b
[ 419.969157] ? __pfx_path_mount+0x10/0x10
[ 419.969594] ? kmem_cache_free+0x1e2/0x260
[ 419.970311] do_mount+0x99/0xe0
[ 419.970630] ? __pfx_do_mount+0x10/0x10
[ 419.971008] __do_sys_mount+0x199/0x1c9
[ 419.971397] do_syscall_64+0xd0/0x135
[ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 419.972233] RIP: 0033:0x7c3cb812972e
[ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48
[ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5
[ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e
[ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI:
---truncated---
CVSS Score
7.8
EPSS Score
0.0
Published
2024-12-27
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: Fix NULL pointer dereference in object->file
At present, the object->file has the NULL pointer dereference problem in
ondemand-mode. The root cause is that the allocated fd and object->file
lifetime are inconsistent, and the user-space invocation to anon_fd uses
object->file. Following is the process that triggers the issue:
[write fd] [umount]
cachefiles_ondemand_fd_write_iter
fscache_cookie_state_machine
cachefiles_withdraw_cookie
if (!file) return -ENOBUFS
cachefiles_clean_up_object
cachefiles_unmark_inode_in_use
fput(object->file)
object->file = NULL
// file NULL pointer dereference!
__cachefiles_write(..., file, ...)
Fix this issue by add an additional reference count to the object->file
before write/llseek, and decrement after it finished.
CVSS Score
5.5
EPSS Score
0.001
Published
2024-12-27