Security Vulnerabilities
- CVEs Published In 2024
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat/qat_420xx - fix off by one in uof_get_name()
This is called from uof_get_name_420xx() where "num_objs" is the
ARRAY_SIZE() of fw_objs[]. The > needs to be >= to prevent an out of
bounds access.
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: glink: fix off-by-one in connector_status
UCSI connector's indices start from 1 up to 3, PMIC_GLINK_MAX_PORTS.
Correct the condition in the pmic_glink_ucsi_connector_status()
callback, fixing Type-C orientation reporting for the third USB-C
connector.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix out of bounds reads when finding clock sources
The current USB-audio driver code doesn't check bLength of each
descriptor at traversing for clock descriptors. That is, when a
device provides a bogus descriptor with a shorter bLength, the driver
might hit out-of-bounds reads.
For addressing it, this patch adds sanity checks to the validator
functions for the clock descriptor traversal. When the descriptor
length is shorter than expected, it's skipped in the loop.
For the clock source and clock multiplier descriptors, we can just
check bLength against the sizeof() of each descriptor type.
OTOH, the clock selector descriptor of UAC2 and UAC3 has an array
of bNrInPins elements and two more fields at its tail, hence those
have to be checked in addition to the sizeof() check.
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: Address an integer overflow
Dan Carpenter reports:
> Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data
> structure") from Jun 22, 2020 (linux-next), leads to the following
> Smatch static checker warning:
>
> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk()
> warn: potential user controlled sizeof overflow 'segcount * 4 * 4'
>
> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt)
> 489 {
> 490 u32 segcount;
> 491 __be32 *p;
> 492
> 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount))
> ^^^^^^^^
>
> 494 return false;
> 495
> 496 /* A bogus segcount causes this buffer overflow check to fail. */
> 497 p = xdr_inline_decode(&rctxt->rc_stream,
> --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p));
>
>
> segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will
> have an integer overflow and some those values will be accepted by
> xdr_inline_decode().
In the Linux kernel, the following vulnerability has been resolved:
clk: clk-apple-nco: Add NULL check in applnco_probe
Add NULL check in applnco_probe, to handle kernel NULL pointer
dereference error.
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix uninitialized value in ocfs2_file_read_iter()
Syzbot has reported the following KMSAN splat:
BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80
ocfs2_file_read_iter+0x9a4/0xf80
__io_read+0x8d4/0x20f0
io_read+0x3e/0xf0
io_issue_sqe+0x42b/0x22c0
io_wq_submit_work+0xaf9/0xdc0
io_worker_handle_work+0xd13/0x2110
io_wq_worker+0x447/0x1410
ret_from_fork+0x6f/0x90
ret_from_fork_asm+0x1a/0x30
Uninit was created at:
__alloc_pages_noprof+0x9a7/0xe00
alloc_pages_mpol_noprof+0x299/0x990
alloc_pages_noprof+0x1bf/0x1e0
allocate_slab+0x33a/0x1250
___slab_alloc+0x12ef/0x35e0
kmem_cache_alloc_bulk_noprof+0x486/0x1330
__io_alloc_req_refill+0x84/0x560
io_submit_sqes+0x172f/0x2f30
__se_sys_io_uring_enter+0x406/0x41c0
__x64_sys_io_uring_enter+0x11f/0x1a0
x64_sys_call+0x2b54/0x3ba0
do_syscall_64+0xcd/0x1e0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Since an instance of 'struct kiocb' may be passed from the block layer
with 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()'
and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in
'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()
I found the following bug in my fuzzer:
UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51
index 255 is out of range for type 'htc_endpoint [22]'
CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: events request_firmware_work_func
Call Trace:
<TASK>
dump_stack_lvl+0x180/0x1b0
__ubsan_handle_out_of_bounds+0xd4/0x130
htc_issue_send.constprop.0+0x20c/0x230
? _raw_spin_unlock_irqrestore+0x3c/0x70
ath9k_wmi_cmd+0x41d/0x610
? mark_held_locks+0x9f/0xe0
...
Since this bug has been confirmed to be caused by insufficient verification
of conn_rsp_epid, I think it would be appropriate to add a range check for
conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scpi: Check the DVFS OPP count returned by the firmware
Fix a kernel crash with the below call trace when the SCPI firmware
returns OPP count of zero.
dvfs_info.opp_count may be zero on some platforms during the reboot
test, and the kernel will crash after dereferencing the pointer to
kcalloc(info->count, sizeof(*opp), GFP_KERNEL).
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028
| Mem abort info:
| ESR = 0x96000004
| Exception class = DABT (current EL), IL = 32 bits
| SET = 0, FnV = 0
| EA = 0, S1PTW = 0
| Data abort info:
| ISV = 0, ISS = 0x00000004
| CM = 0, WnR = 0
| user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c
| [0000000000000028] pgd=0000000000000000
| Internal error: Oops: 96000004 [#1] SMP
| scpi-hwmon: probe of PHYT000D:00 failed with error -110
| Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c)
| CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1
| Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS
| pstate: 60000005 (nZCv daif -PAN -UAO)
| pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
| lr : clk_register+0x438/0x720
| Call trace:
| scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
| devm_clk_hw_register+0x50/0xa0
| scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi]
| scpi_clocks_probe+0x528/0x70c [clk_scpi]
| platform_drv_probe+0x58/0xa8
| really_probe+0x260/0x3d0
| driver_probe_device+0x12c/0x148
| device_driver_attach+0x74/0x98
| __driver_attach+0xb4/0xe8
| bus_for_each_dev+0x88/0xe0
| driver_attach+0x30/0x40
| bus_add_driver+0x178/0x2b0
| driver_register+0x64/0x118
| __platform_driver_register+0x54/0x60
| scpi_clocks_driver_init+0x24/0x1000 [clk_scpi]
| do_one_initcall+0x54/0x220
| do_init_module+0x54/0x1c8
| load_module+0x14a4/0x1668
| __se_sys_finit_module+0xf8/0x110
| __arm64_sys_finit_module+0x24/0x30
| el0_svc_common+0x78/0x170
| el0_svc_handler+0x38/0x78
| el0_svc+0x8/0x340
| Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820)
| ---[ end trace 06feb22469d89fa8 ]---
| Kernel panic - not syncing: Fatal exception
| SMP: stopping secondary CPUs
| Kernel Offset: disabled
| CPU features: 0x10,a0002008
| Memory Limit: none
In the Linux kernel, the following vulnerability has been resolved:
um: Fix potential integer overflow during physmem setup
This issue happens when the real map size is greater than LONG_MAX,
which can be easily triggered on UML/i386.
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Prevent a potential integer overflow
If the tag length is >= U32_MAX - 3 then the "length + 4" addition
can result in an integer overflow. Address this by splitting the
decoding into several steps so that decode_cb_compound4res() does
not have to perform arithmetic on the unsafe length value.