Linux: >> Linux Kernel >> 4.14.298 Security Vulnerabilities
In the Linux kernel, the following vulnerability has been resolved:
clk: samsung: Fix memory leak in _samsung_clk_register_pll()
If clk_register() fails, @pll->rate_table may have allocated memory by
kmemdup(), so it needs to be freed, otherwise will cause memory leak
issue, this patch fixes it.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-10-01
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Validate the box size for the snooped cursor
Invalid userspace dma surface copies could potentially overflow
the memcpy from the surface to the snooped image leading to crashes.
To fix it the dimensions of the copybox have to be validated
against the expected size of the snooped cursor.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-10-01
In the Linux kernel, the following vulnerability has been resolved:
xfrm: Reinject transport-mode packets through workqueue
The following warning is displayed when the tcp6-multi-diffip11 stress
test case of the LTP test suite is tested:
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ns-tcpserver:48198]
CPU: 0 PID: 48198 Comm: ns-tcpserver Kdump: loaded Not tainted 6.0.0-rc6+ #39
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : des3_ede_encrypt+0x27c/0x460 [libdes]
lr : 0x3f
sp : ffff80000ceaa1b0
x29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280
x26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003b
x23: 0000000000802080 x22: 000000000000003d x21: 0000000000000038
x20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033
x17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248
x14: ffff0000e51e4680 x13: ffff80004e2d1348 x12: ffff80004e2d1548
x11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748
x8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001b
x5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 : 000000007f1dd0a3
x2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872
Call trace:
des3_ede_encrypt+0x27c/0x460 [libdes]
crypto_des3_ede_encrypt+0x1c/0x30 [des_generic]
crypto_cbc_encrypt+0x148/0x190
crypto_skcipher_encrypt+0x2c/0x40
crypto_authenc_encrypt+0xc8/0xfc [authenc]
crypto_aead_encrypt+0x2c/0x40
echainiv_encrypt+0x144/0x1a0 [echainiv]
crypto_aead_encrypt+0x2c/0x40
esp6_output_tail+0x1c8/0x5d0 [esp6]
esp6_output+0x120/0x278 [esp6]
xfrm_output_one+0x458/0x4ec
xfrm_output_resume+0x6c/0x1f0
xfrm_output+0xac/0x4ac
__xfrm6_output+0x130/0x270
xfrm6_output+0x60/0xec
ip6_xmit+0x2ec/0x5bc
inet6_csk_xmit+0xbc/0x10c
__tcp_transmit_skb+0x460/0x8c0
tcp_write_xmit+0x348/0x890
__tcp_push_pending_frames+0x44/0x110
tcp_rcv_established+0x3c8/0x720
tcp_v6_do_rcv+0xdc/0x4a0
tcp_v6_rcv+0xc24/0xcb0
ip6_protocol_deliver_rcu+0xf0/0x574
ip6_input_finish+0x48/0x7c
ip6_input+0x48/0xc0
ip6_rcv_finish+0x80/0x9c
xfrm_trans_reinject+0xb0/0xf4
tasklet_action_common.constprop.0+0xf8/0x134
tasklet_action+0x30/0x3c
__do_softirq+0x128/0x368
do_softirq+0xb4/0xc0
__local_bh_enable_ip+0xb0/0xb4
put_cpu_fpsimd_context+0x40/0x70
kernel_neon_end+0x20/0x40
sha1_base_do_update.constprop.0.isra.0+0x11c/0x140 [sha1_ce]
sha1_ce_finup+0x94/0x110 [sha1_ce]
crypto_shash_finup+0x34/0xc0
hmac_finup+0x48/0xe0
crypto_shash_finup+0x34/0xc0
shash_digest_unaligned+0x74/0x90
crypto_shash_digest+0x4c/0x9c
shash_ahash_digest+0xc8/0xf0
shash_async_digest+0x28/0x34
crypto_ahash_digest+0x48/0xcc
crypto_authenc_genicv+0x88/0xcc [authenc]
crypto_authenc_encrypt+0xd8/0xfc [authenc]
crypto_aead_encrypt+0x2c/0x40
echainiv_encrypt+0x144/0x1a0 [echainiv]
crypto_aead_encrypt+0x2c/0x40
esp6_output_tail+0x1c8/0x5d0 [esp6]
esp6_output+0x120/0x278 [esp6]
xfrm_output_one+0x458/0x4ec
xfrm_output_resume+0x6c/0x1f0
xfrm_output+0xac/0x4ac
__xfrm6_output+0x130/0x270
xfrm6_output+0x60/0xec
ip6_xmit+0x2ec/0x5bc
inet6_csk_xmit+0xbc/0x10c
__tcp_transmit_skb+0x460/0x8c0
tcp_write_xmit+0x348/0x890
__tcp_push_pending_frames+0x44/0x110
tcp_push+0xb4/0x14c
tcp_sendmsg_locked+0x71c/0xb64
tcp_sendmsg+0x40/0x6c
inet6_sendmsg+0x4c/0x80
sock_sendmsg+0x5c/0x6c
__sys_sendto+0x128/0x15c
__arm64_sys_sendto+0x30/0x40
invoke_syscall+0x50/0x120
el0_svc_common.constprop.0+0x170/0x194
do_el0_svc+0x38/0x4c
el0_svc+0x28/0xe0
el0t_64_sync_handler+0xbc/0x13c
el0t_64_sync+0x180/0x184
Get softirq info by bcc tool:
./softirqs -NT 10
Tracing soft irq event time... Hit Ctrl-C to end.
15:34:34
SOFTIRQ TOTAL_nsecs
block 158990
timer 20030920
sched 46577080
net_rx 676746820
tasklet 9906067650
15:34:45
SOFTIRQ TOTAL_nsecs
block 86100
sched 38849790
net_rx
---truncated---
CVSS Score
5.5
EPSS Score
0.0
Published
2025-10-01
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: fix possible memleak when register 'hctx' failed
There's issue as follows when do fault injection test:
unreferenced object 0xffff888132a9f400 (size 512):
comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff ...........2....
08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00 ...2............
backtrace:
[<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0
[<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0
[<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230
[<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910
[<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0
[<00000000a2a34657>] 0xffffffffa2ad310f
[<00000000b173f718>] 0xffffffffa2af824a
[<0000000095a1dabb>] do_one_initcall+0x87/0x2a0
[<00000000f32fdf93>] do_init_module+0xdf/0x320
[<00000000cbe8541e>] load_module+0x3006/0x3390
[<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0
[<00000000a1a29ae8>] do_syscall_64+0x35/0x80
[<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Fault injection context as follows:
kobject_add
blk_mq_register_hctx
blk_mq_sysfs_register
blk_register_queue
device_add_disk
null_add_dev.part.0 [null_blk]
As 'blk_mq_register_hctx' may already add some objects when failed halfway,
but there isn't do fallback, caller don't know which objects add failed.
To solve above issue just do fallback when add objects failed halfway in
'blk_mq_register_hctx'.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-10-01
In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8173: Enable IRQ when pdata is ready
If the device does not come straight from reset, we might receive an IRQ
before we are ready to handle it.
[ 2.334737] Unable to handle kernel read from unreadable memory at virtual address 00000000000001e4
[ 2.522601] Call trace:
[ 2.525040] regmap_read+0x1c/0x80
[ 2.528434] mt8173_afe_irq_handler+0x40/0xf0
...
[ 2.598921] start_kernel+0x338/0x42c
CVSS Score
5.5
EPSS Score
0.0
Published
2025-10-01
In the Linux kernel, the following vulnerability has been resolved:
mmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING
vub300_enable_sdio_irq() works with mutex and need TASK_RUNNING here.
Ensure that we mark current as TASK_RUNNING for sleepable context.
[ 77.554641] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff92a72c1d>] sdio_irq_thread+0x17d/0x5b0
[ 77.554652] WARNING: CPU: 2 PID: 1983 at kernel/sched/core.c:9813 __might_sleep+0x116/0x160
[ 77.554905] CPU: 2 PID: 1983 Comm: ksdioirqd/mmc1 Tainted: G OE 6.1.0-rc5 #1
[ 77.554910] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020
[ 77.554912] RIP: 0010:__might_sleep+0x116/0x160
[ 77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282
[ 77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000
[ 77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9
[ 77.554928] RBP: ffff888107b7fde0 R08: 0000000000000001 R09: ffffed1043ea60ba
[ 77.554930] R10: ffff88821f5305cb R11: ffffed1043ea60b9 R12: ffffffff93aa3a60
[ 77.554932] R13: 000000000000011b R14: 7fffffffffffffff R15: ffffffffc0558660
[ 77.554934] FS: 0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000
[ 77.554937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 77.554939] CR2: 00007f8a44010d68 CR3: 000000024421a003 CR4: 00000000003706e0
[ 77.554942] Call Trace:
[ 77.554944] <TASK>
[ 77.554952] mutex_lock+0x78/0xf0
[ 77.554973] vub300_enable_sdio_irq+0x103/0x3c0 [vub300]
[ 77.554981] sdio_irq_thread+0x25c/0x5b0
[ 77.555006] kthread+0x2b8/0x370
[ 77.555017] ret_from_fork+0x1f/0x30
[ 77.555023] </TASK>
[ 77.555025] ---[ end trace 0000000000000000 ]---
CVSS Score
5.5
EPSS Score
0.0
Published
2025-10-01
In the Linux kernel, the following vulnerability has been resolved:
scsi: libsas: Fix use-after-free bug in smp_execute_task_sg()
When executing SMP task failed, the smp_execute_task_sg() calls del_timer()
to delete "slow_task->timer". However, if the timer handler
sas_task_internal_timedout() is running, the del_timer() in
smp_execute_task_sg() will not stop it and a UAF will happen. The process
is shown below:
(thread 1) | (thread 2)
smp_execute_task_sg() | sas_task_internal_timedout()
... |
del_timer() |
... | ...
sas_free_task(task) |
kfree(task->slow_task) //FREE|
| task->slow_task->... //USE
Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure
the timer handler have finished before the "task->slow_task" is
deallocated.
CVSS Score
7.8
EPSS Score
0.0
Published
2025-10-01
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()
There is an use-after-free reported by KASAN:
BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82
Read of size 1 at addr ffff888112afc460 by task modprobe/2111
CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
Call Trace:
<TASK>
kasan_report+0xae/0xe0
acpi_ut_remove_reference+0x3b/0x82
acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5
acpi_ds_store_object_to_local+0x15d/0x3a0
acpi_ex_store+0x78d/0x7fd
acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b
acpi_ps_parse_aml+0x217/0x8d5
...
</TASK>
The root cause of the problem is that the acpi_operand_object
is freed when acpi_ut_walk_package_tree() fails in
acpi_ut_copy_ipackage_to_ipackage(), lead to repeated release in
acpi_ut_copy_iobject_to_iobject(). The problem was introduced
by "8aa5e56eeb61" commit, this commit is to fix memory leak in
acpi_ut_copy_iobject_to_iobject(), repeatedly adding remove
operation, lead to "acpi_operand_object" used after free.
Fix it by removing acpi_ut_remove_reference() in
acpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage()
is called to copy an internal package object into another internal
package object, when it fails, the memory of acpi_operand_object
should be freed by the caller.
CVSS Score
7.8
EPSS Score
0.0
Published
2025-10-01
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix UBSAN shift-out-of-bounds warning
If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up
doing a shift operation where the number of bits shifted equals
number of bits in the operand. This behaviour is undefined.
Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the
count is >= number of bits in the operand.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472
CVSS Score
7.1
EPSS Score
0.0
Published
2025-10-01
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix race condition validating r_parent before applying state
Add validation to ensure the cached parent directory inode matches the
directory info in MDS replies. This prevents client-side race conditions
where concurrent operations (e.g. rename) cause r_parent to become stale
between request initiation and reply processing, which could lead to
applying state changes to incorrect directory inodes.
[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to
move CEPH_CAP_PIN reference when r_parent is updated:
When the parent directory lock is not held, req->r_parent can become
stale and is updated to point to the correct inode. However, the
associated CEPH_CAP_PIN reference was not being adjusted. The
CEPH_CAP_PIN is a reference on an inode that is tracked for
accounting purposes. Moving this pin is important to keep the
accounting balanced. When the pin was not moved from the old parent
to the new one, it created two problems: The reference on the old,
stale parent was never released, causing a reference leak.
A reference for the new parent was never acquired, creating the risk
of a reference underflow later in ceph_mdsc_release_request(). This
patch corrects the logic by releasing the pin from the old parent and
acquiring it for the new parent when r_parent is switched. This
ensures reference accounting stays balanced. ]
CVSS Score
4.7
EPSS Score
0.0
Published
2025-10-01