Security Vulnerabilities - CVEs Published In 2024
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down
There is a history of deadlock if reboot is performed at the beginning
of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS
shutdown, and at that time the audio driver was waiting on
blk_mq_submit_bio() holding a mutex_lock while reading the fw binary.
After that, a deadlock issue occurred while audio driver shutdown was
waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set
SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down
after a UFS shutdown will return an error.
[ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown]
[ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49]
[ 31.907806]I[0: swapper/0: 0] Call trace:
[ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338
[ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc
[ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8
[ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40
[ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac
[ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24
[ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec
[ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280
[ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c
[ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280
[ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158
[ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4
[ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0
[ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0
[ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4
[ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4
[ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter]
[ 31.908783]I[0: swapper/0: 0] Call trace:
[ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338
[ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc
[ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8
[ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178
[ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c
[ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c
CVSS Score
5.5
EPSS Score
0.002
Published
2024-11-05
In the Linux kernel, the following vulnerability has been resolved:
arm64: probes: Remove broken LDR (literal) uprobe support
The simulate_ldr_literal() and simulate_ldrsw_literal() functions are
unsafe to use for uprobes. Both functions were originally written for
use with kprobes, and access memory with plain C accesses. When uprobes
was added, these were reused unmodified even though they cannot safely
access user memory.
There are three key problems:
1) The plain C accesses do not have corresponding extable entries, and
thus if they encounter a fault the kernel will treat these as
unintentional accesses to user memory, resulting in a BUG() which
will kill the kernel thread, and likely lead to further issues (e.g.
lockup or panic()).
2) The plain C accesses are subject to HW PAN and SW PAN, and so when
either is in use, any attempt to simulate an access to user memory
will fault. Thus neither simulate_ldr_literal() nor
simulate_ldrsw_literal() can do anything useful when simulating a
user instruction on any system with HW PAN or SW PAN.
3) The plain C accesses are privileged, as they run in kernel context,
and in practice can access a small range of kernel virtual addresses.
The instructions they simulate have a range of +/-1MiB, and since the
simulated instructions must itself be a user instructions in the
TTBR0 address range, these can address the final 1MiB of the TTBR1
acddress range by wrapping downwards from an address in the first
1MiB of the TTBR0 address range.
In contemporary kernels the last 8MiB of TTBR1 address range is
reserved, and accesses to this will always fault, meaning this is no
worse than (1).
Historically, it was theoretically possible for the linear map or
vmemmap to spill into the final 8MiB of the TTBR1 address range, but
in practice this is extremely unlikely to occur as this would
require either:
* Having enough physical memory to fill the entire linear map all the
way to the final 1MiB of the TTBR1 address range.
* Getting unlucky with KASLR randomization of the linear map such
that the populated region happens to overlap with the last 1MiB of
the TTBR address range.
... and in either case if we were to spill into the final page there
would be larger problems as the final page would alias with error
pointers.
Practically speaking, (1) and (2) are the big issues. Given there have
been no reports of problems since the broken code was introduced, it
appears that no-one is relying on probing these instructions with
uprobes.
Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW
(literal), limiting the use of simulate_ldr_literal() and
simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR
(literal) and LDRSW (literal) will be rejected as
arm_probe_decode_insn() will return INSN_REJECTED. In future we can
consider introducing working uprobes support for these instructions, but
this will require more significant work.
CVSS Score
7.3
EPSS Score
0.003
Published
2024-11-05
In the Linux kernel, the following vulnerability has been resolved:
USB: gadget: dummy-hcd: Fix "task hung" problem
The syzbot fuzzer has been encountering "task hung" problems ever
since the dummy-hcd driver was changed to use hrtimers instead of
regular timers. It turns out that the problems are caused by a subtle
difference between the timer_pending() and hrtimer_active() APIs.
The changeover blindly replaced the first by the second. However,
timer_pending() returns True when the timer is queued but not when its
callback is running, whereas hrtimer_active() returns True when the
hrtimer is queued _or_ its callback is running. This difference
occasionally caused dummy_urb_enqueue() to think that the callback
routine had not yet started when in fact it was almost finished. As a
result the hrtimer was not restarted, which made it impossible for the
driver to dequeue later the URB that was just enqueued. This caused
usb_kill_urb() to hang, and things got worse from there.
Since hrtimers have no API for telling when they are queued and the
callback isn't running, the driver must keep track of this for itself.
That's what this patch does, adding a new "timer_pending" flag and
setting or clearing it at the appropriate times.
CVSS Score
5.5
EPSS Score
0.002
Published
2024-11-05
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices
Previously, the domain_context_clear() function incorrectly called
pci_for_each_dma_alias() to set up context entries for non-PCI devices.
This could lead to kernel hangs or other unexpected behavior.
Add a check to only call pci_for_each_dma_alias() for PCI devices. For
non-PCI devices, domain_context_clear_one() is called directly.
CVSS Score
7.8
EPSS Score
0.002
Published
2024-11-05
In the Linux kernel, the following vulnerability has been resolved:
x86: fix user address masking non-canonical speculation issue
It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical
accesses in kernel space. And so using just the high bit to decide
whether an access is in user space or kernel space ends up with the good
old "leak speculative data" if you have the right gadget using the
result:
CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“
Now, the kernel surrounds the access with a STAC/CLAC pair, and those
instructions end up serializing execution on older Zen architectures,
which closes the speculation window.
But that was true only up until Zen 5, which renames the AC bit [1].
That improves performance of STAC/CLAC a lot, but also means that the
speculation window is now open.
Note that this affects not just the new address masking, but also the
regular valid_user_address() check used by access_ok(), and the asm
version of the sign bit check in the get_user() helpers.
It does not affect put_user() or clear_user() variants, since there's no
speculative result to be used in a gadget for those operations.
CVSS Score
5.5
EPSS Score
0.002
Published
2024-11-05
In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()
A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could
possibly return NULL pointer. NULL Pointer Dereference may be
triggerred without addtional check.
Add a NULL check for the returned pointer.
CVSS Score
5.5
EPSS Score
0.002
Published
2024-11-05
In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: sdm845: add missing soundwire runtime stream alloc
During the migration of Soundwire runtime stream allocation from
the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845
soundcard was forgotten.
At this point any playback attempt or audio daemon startup, for instance
on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer
NULL dereference:
Unable to handle kernel NULL pointer dereference at virtual
address 0000000000000020
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000
[0000000000000020] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
Modules linked in: ...
CPU: 5 UID: 0 PID: 1198 Comm: aplay
Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty #18
Hardware name: Thundercomm Dragonboard 845c (DT)
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
sp : ffff80008a2035c0
x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000
x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800
x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003
x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000
x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec
x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003
x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8
Call trace:
sdw_stream_add_slave+0x44/0x380 [soundwire_bus]
wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x]
snd_soc_dai_hw_params+0x3c/0xa4
__soc_pcm_hw_params+0x230/0x660
dpcm_be_dai_hw_params+0x1d0/0x3f8
dpcm_fe_dai_hw_params+0x98/0x268
snd_pcm_hw_params+0x124/0x460
snd_pcm_common_ioctl+0x998/0x16e8
snd_pcm_ioctl+0x34/0x58
__arm64_sys_ioctl+0xac/0xf8
invoke_syscall+0x48/0x104
el0_svc_common.constprop.0+0x40/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x34/0xe0
el0t_64_sync_handler+0x120/0x12c
el0t_64_sync+0x190/0x194
Code: aa0403fb f9418400 9100e000 9400102f (f8420f22)
---[ end trace 0000000000000000 ]---
0000000000006108 <sdw_stream_add_slave>:
6108: d503233f paciasp
610c: a9b97bfd stp x29, x30, [sp, #-112]!
6110: 910003fd mov x29, sp
6114: a90153f3 stp x19, x20, [sp, #16]
6118: a9025bf5 stp x21, x22, [sp, #32]
611c: aa0103f6 mov x22, x1
6120: 2a0303f5 mov w21, w3
6124: a90363f7 stp x23, x24, [sp, #48]
6128: aa0003f8 mov x24, x0
612c: aa0203f7 mov x23, x2
6130: a9046bf9 stp x25, x26, [sp, #64]
6134: aa0403f9 mov x25, x4 <-- x4 copied to x25
6138: a90573fb stp x27, x28, [sp, #80]
613c: aa0403fb mov x27, x4
6140: f9418400 ldr x0, [x0, #776]
6144: 9100e000 add x0, x0, #0x38
6148: 94000000 bl 0 <mutex_lock>
614c: f8420f22 ldr x2, [x25, #32]! <-- offset 0x44
^^^
This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave()
where data abort happens.
wsa881x_hw_params() is called with stream = NULL and passes it further
in register x4 (5th argu
---truncated---
CVSS Score
5.5
EPSS Score
0.002
Published
2024-11-05
A potential vulnerability was discovered in certain Poly video conferencing devices. The firmware flaw does not properly sanitize user input. The exploitation of this vulnerability is dependent on a layered attack and cannot be exploited by itself.
CVSS Score
7.5
EPSS Score
0.004
Published
2024-11-05
Substance3D - Painter versions 10.0.1 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
CVSS Score
7.8
EPSS Score
0.003
Published
2024-11-05
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/oa: Fix overflow in oa batch buffer
By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch
buffer, this is not a problem if batch buffer is only used once but
oa reuses the batch buffer for the same metric and at each call
it appends a MI_BATCH_BUFFER_END, printing the warning below and then
overflowing.
[ 381.072016] ------------[ cut here ]------------
[ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed!
platform: LUNARLAKE subplatform: 1
graphics: Xe2_LPG / Xe2_HPG 20.04 step B0
media: Xe2_LPM / Xe2_HPM 20.00 step B0
tile: 0 VRAM 0 B
GT: 0 type 1
So here checking if batch buffer already have MI_BATCH_BUFFER_END if
not append it.
v2:
- simply fix, suggestion from Ashutosh
(cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)
CVSS Score
7.8
EPSS Score
0.002
Published
2024-11-05