Linux: >> Linux Kernel >> 4.11.1 Security Vulnerabilities
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix memory leak in mes self test
The fences associated with mes queue have to be freed
up during amdgpu_ring_fini.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-18
In the Linux kernel, the following vulnerability has been resolved:
crypto: seqiv - Handle EBUSY correctly
As it is seqiv only handles the special return value of EINPROGERSS,
which means that in all other cases it will free data related to the
request.
However, as the caller of seqiv may specify MAY_BACKLOG, we also need
to expect EBUSY and treat it in the same way. Otherwise backlogged
requests will trigger a use-after-free.
CVSS Score
7.8
EPSS Score
0.0
Published
2025-09-18
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: SDMA update use unlocked iterator
SDMA update page table may be called from unlocked context, this
generate below warning. Use unlocked iterator to handle this case.
WARNING: CPU: 0 PID: 1475 at
drivers/dma-buf/dma-resv.c:483 dma_resv_iter_next
Call Trace:
dma_resv_iter_first+0x43/0xa0
amdgpu_vm_sdma_update+0x69/0x2d0 [amdgpu]
amdgpu_vm_ptes_update+0x29c/0x870 [amdgpu]
amdgpu_vm_update_range+0x2f6/0x6c0 [amdgpu]
svm_range_unmap_from_gpus+0x115/0x300 [amdgpu]
svm_range_cpu_invalidate_pagetables+0x510/0x5e0 [amdgpu]
__mmu_notifier_invalidate_range_start+0x1d3/0x230
unmap_vmas+0x140/0x150
unmap_region+0xa8/0x110
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-18
In the Linux kernel, the following vulnerability has been resolved:
i2c: ismt: Fix an out-of-bounds bug in ismt_access()
When the driver does not check the data from the user, the variable
'data->block[0]' may be very large to cause an out-of-bounds bug.
The following log can reveal it:
[ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20
[ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE
[ 33.996475] ==================================================================
[ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b
[ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485
[ 33.999450] Call Trace:
[ 34.001849] memcpy+0x20/0x60
[ 34.002077] ismt_access.cold+0x374/0x214b
[ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0
[ 34.004007] i2c_smbus_xfer+0x10a/0x390
[ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710
[ 34.005196] i2cdev_ioctl+0x5ec/0x74c
Fix this bug by checking the size of 'data->block[0]' first.
CVSS Score
7.1
EPSS Score
0.0
Published
2025-09-18
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix memory leak in tcindex_set_parms
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810c287f00 (size 256):
comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046
[<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [inline]
[<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [inline]
[<ffffffff839c9e07>] kcalloc include/linux/slab.h:659 [inline]
[<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline]
[<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342
[<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553
[<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147
[<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082
[<ffffffff839eba67>] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540
[<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
[<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345
[<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921
[<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [inline]
[<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734
[<ffffffff8383eb08>] ____sys_sendmsg+0x178/0x410 net/socket.c:2482
[<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536
[<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622
[<ffffffff83843c14>] __do_sys_sendmmsg net/socket.c:2651 [inline]
[<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline]
[<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648
[<ffffffff84605fd5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
====================================
Kernel uses tcindex_change() to change an existing
filter properties.
Yet the problem is that, during the process of changing,
if `old_r` is retrieved from `p->perfect`, then
kernel uses tcindex_alloc_perfect_hash() to newly
allocate filter results, uses tcindex_filter_result_init()
to clear the old filter result, without destroying
its tcf_exts structure, which triggers the above memory leak.
To be more specific, there are only two source for the `old_r`,
according to the tcindex_lookup(). `old_r` is retrieved from
`p->perfect`, or `old_r` is retrieved from `p->h`.
* If `old_r` is retrieved from `p->perfect`, kernel uses
tcindex_alloc_perfect_hash() to newly allocate the
filter results. Then `r` is assigned with `cp->perfect + handle`,
which is newly allocated. So condition `old_r && old_r != r` is
true in this situation, and kernel uses tcindex_filter_result_init()
to clear the old filter result, without destroying
its tcf_exts structure
* If `old_r` is retrieved from `p->h`, then `p->perfect` is NULL
according to the tcindex_lookup(). Considering that `cp->h`
is directly copied from `p->h` and `p->perfect` is NULL,
`r` is assigned with `tcindex_lookup(cp, handle)`, whose value
should be the same as `old_r`, so condition `old_r && old_r != r`
is false in this situation, kernel ignores using
tcindex_filter_result_init() to clear the old filter result.
So only when `old_r` is retrieved from `p->perfect` does kernel use
tcindex_filter_result_init() to clear the old filter result, which
triggers the above memory leak.
Considering that there already exists a tc_filter_wq workqueue
to destroy the old tcindex_d
---truncated---
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-18
In the Linux kernel, the following vulnerability has been resolved:
staging: vme_user: Fix possible UAF in tsi148_dma_list_add
Smatch report warning as follows:
drivers/staging/vme_user/vme_tsi148.c:1757 tsi148_dma_list_add() warn:
'&entry->list' not removed from list
In tsi148_dma_list_add(), the error path "goto err_dma" will not
remove entry->list from list->entries, but entry will be freed,
then list traversal may cause UAF.
Fix by removeing it from list->entries before free().
CVSS Score
7.8
EPSS Score
0.0
Published
2025-09-18
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix an Oops in nfs_d_automount()
When mounting from a NFSv4 referral, path->dentry can end up being a
negative dentry, so derive the struct nfs_server from the dentry
itself instead.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-18
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix user-after-free
This uses l2cap_chan_hold_unless_zero() after calling
__l2cap_get_chan_blah() to prevent the following trace:
Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref
*kref)
Bluetooth: chan 0000000023c4974d
Bluetooth: parent 00000000ae861c08
==================================================================
BUG: KASAN: use-after-free in __mutex_waiter_is_first
kernel/locking/mutex.c:191 [inline]
BUG: KASAN: use-after-free in __mutex_lock_common
kernel/locking/mutex.c:671 [inline]
BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400
kernel/locking/mutex.c:729
Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389
CVSS Score
8.0
EPSS Score
0.001
Published
2025-09-18
In the Linux kernel, the following vulnerability has been resolved:
tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak
In crb_acpi_add(), we get the TPM2 table to retrieve information
like start method, and then assign them to the priv data, so the
TPM2 table is not used after the init, should be freed, call
acpi_put_table() to fix the memory leak.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-18
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: fsl_lpuart: disable dma rx/tx use flags in lpuart_dma_shutdown
lpuart_dma_shutdown tears down lpuart dma, but lpuart_flush_buffer can
still occur which in turn tries to access dma apis if lpuart_dma_tx_use
flag is true. At this point since dma is torn down, these dma apis can
abort. Set lpuart_dma_tx_use and the corresponding rx flag
lpuart_dma_rx_use to false in lpuart_dma_shutdown so that dmas are not
accessed after they are relinquished.
Otherwise, when try to kill btattach, kernel may panic. This patch may
fix this issue.
root@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200
^C[ 90.182296] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
[ 90.189806] Modules linked in: moal(O) mlan(O)
[ 90.194258] CPU: 0 PID: 503 Comm: btattach Tainted: G O 5.15.32-06136-g34eecdf2f9e4 #37
[ 90.203554] Hardware name: NXP i.MX8ULP 9X9 EVK (DT)
[ 90.208513] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 90.215470] pc : fsl_edma3_disable_request+0x8/0x60
[ 90.220358] lr : fsl_edma3_terminate_all+0x34/0x20c
[ 90.225237] sp : ffff800013f0bac0
[ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800
[ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24: ffff000008404a00
[ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000
[ 90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000
[ 90.257078] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 90.264211] x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000040
[ 90.271344] x11: ffff00000600c248 x10: ffff800013f0bb10 x9 : ffff000057bcb090
[ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804
[ 90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480
[ 90.292742] x2 : ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800
[ 90.299876] Call trace:
[ 90.302321] fsl_edma3_disable_request+0x8/0x60
[ 90.306851] lpuart_flush_buffer+0x40/0x160
[ 90.311037] uart_flush_buffer+0x88/0x120
[ 90.315050] tty_driver_flush_buffer+0x20/0x30
[ 90.319496] hci_uart_flush+0x44/0x90
[ 90.323162] +0x34/0x12c
[ 90.327253] tty_ldisc_close+0x38/0x70
[ 90.331005] tty_ldisc_release+0xa8/0x190
[ 90.335018] tty_release_struct+0x24/0x8c
[ 90.339022] tty_release+0x3ec/0x4c0
[ 90.342593] __fput+0x70/0x234
[ 90.345652] ____fput+0x14/0x20
[ 90.348790] task_work_run+0x84/0x17c
[ 90.352455] do_exit+0x310/0x96c
[ 90.355688] do_group_exit+0x3c/0xa0
[ 90.359259] __arm64_sys_exit_group+0x1c/0x20
[ 90.363609] invoke_syscall+0x48/0x114
[ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc
[ 90.372068] do_el0_svc+0x2c/0x94
[ 90.375379] el0_svc+0x28/0x80
[ 90.378438] el0t_64_sync_handler+0xa8/0x130
[ 90.382711] el0t_64_sync+0x1a0/0x1a4
[ 90.386376] Code: 17ffffda d503201f d503233f f9409802 (b9400041)
[ 90.392467] ---[ end trace 2f60524b4a43f1f6 ]---
[ 90.397073] note: btattach[503] exited with preempt_count 1
[ 90.402636] Fixing recursive fault but reboot is needed!
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-18