Linux: >> Linux Kernel >> 4.14.296 Security Vulnerabilities
In the Linux kernel, the following vulnerability has been resolved:
xfrm: add NULL check in xfrm_update_ae_params
Normally, x->replay_esn and x->preplay_esn should be allocated at
xfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the
xfrm_update_ae_params(...) is okay to update them. However, the current
implementation of xfrm_new_ae(...) allows a malicious user to directly
dereference a NULL pointer and crash the kernel like below.
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0
Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4
RIP: 0010:memcpy_orig+0xad/0x140
Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c
RSP: 0018:ffff888008f57658 EFLAGS: 00000202
RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571
RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818
R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000
FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0
Call Trace:
<TASK>
? __die+0x1f/0x70
? page_fault_oops+0x1e8/0x500
? __pfx_is_prefetch.constprop.0+0x10/0x10
? __pfx_page_fault_oops+0x10/0x10
? _raw_spin_unlock_irqrestore+0x11/0x40
? fixup_exception+0x36/0x460
? _raw_spin_unlock_irqrestore+0x11/0x40
? exc_page_fault+0x5e/0xc0
? asm_exc_page_fault+0x26/0x30
? xfrm_update_ae_params+0xd1/0x260
? memcpy_orig+0xad/0x140
? __pfx__raw_spin_lock_bh+0x10/0x10
xfrm_update_ae_params+0xe7/0x260
xfrm_new_ae+0x298/0x4e0
? __pfx_xfrm_new_ae+0x10/0x10
? __pfx_xfrm_new_ae+0x10/0x10
xfrm_user_rcv_msg+0x25a/0x410
? __pfx_xfrm_user_rcv_msg+0x10/0x10
? __alloc_skb+0xcf/0x210
? stack_trace_save+0x90/0xd0
? filter_irq_stacks+0x1c/0x70
? __stack_depot_save+0x39/0x4e0
? __kasan_slab_free+0x10a/0x190
? kmem_cache_free+0x9c/0x340
? netlink_recvmsg+0x23c/0x660
? sock_recvmsg+0xeb/0xf0
? __sys_recvfrom+0x13c/0x1f0
? __x64_sys_recvfrom+0x71/0x90
? do_syscall_64+0x3f/0x90
? entry_SYSCALL_64_after_hwframe+0x72/0xdc
? copyout+0x3e/0x50
netlink_rcv_skb+0xd6/0x210
? __pfx_xfrm_user_rcv_msg+0x10/0x10
? __pfx_netlink_rcv_skb+0x10/0x10
? __pfx_sock_has_perm+0x10/0x10
? mutex_lock+0x8d/0xe0
? __pfx_mutex_lock+0x10/0x10
xfrm_netlink_rcv+0x44/0x50
netlink_unicast+0x36f/0x4c0
? __pfx_netlink_unicast+0x10/0x10
? netlink_recvmsg+0x500/0x660
netlink_sendmsg+0x3b7/0x700
This Null-ptr-deref bug is assigned CVE-2023-3772. And this commit
adds additional NULL check in xfrm_update_ae_params to fix the NPD.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
igb: Fix igb_down hung on surprise removal
In a setup where a Thunderbolt hub connects to Ethernet and a display
through USB Type-C, users may experience a hung task timeout when they
remove the cable between the PC and the Thunderbolt hub.
This is because the igb_down function is called multiple times when
the Thunderbolt hub is unplugged. For example, the igb_io_error_detected
triggers the first call, and the igb_remove triggers the second call.
The second call to igb_down will block at napi_synchronize.
Here's the call trace:
__schedule+0x3b0/0xddb
? __mod_timer+0x164/0x5d3
schedule+0x44/0xa8
schedule_timeout+0xb2/0x2a4
? run_local_timers+0x4e/0x4e
msleep+0x31/0x38
igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4]
__igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4]
igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4]
__dev_close_many+0x95/0xec
dev_close_many+0x6e/0x103
unregister_netdevice_many+0x105/0x5b1
unregister_netdevice_queue+0xc2/0x10d
unregister_netdev+0x1c/0x23
igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4]
pci_device_remove+0x3f/0x9c
device_release_driver_internal+0xfe/0x1b4
pci_stop_bus_device+0x5b/0x7f
pci_stop_bus_device+0x30/0x7f
pci_stop_bus_device+0x30/0x7f
pci_stop_and_remove_bus_device+0x12/0x19
pciehp_unconfigure_device+0x76/0xe9
pciehp_disable_slot+0x6e/0x131
pciehp_handle_presence_or_link_change+0x7a/0x3f7
pciehp_ist+0xbe/0x194
irq_thread_fn+0x22/0x4d
? irq_thread+0x1fd/0x1fd
irq_thread+0x17b/0x1fd
? irq_forced_thread_fn+0x5f/0x5f
kthread+0x142/0x153
? __irq_get_irqchip_state+0x46/0x46
? kthread_associate_blkcg+0x71/0x71
ret_from_fork+0x1f/0x30
In this case, igb_io_error_detected detaches the network interface
and requests a PCIE slot reset, however, the PCIE reset callback is
not being invoked and thus the Ethernet connection breaks down.
As the PCIE error in this case is a non-fatal one, requesting a
slot reset can be avoided.
This patch fixes the task hung issue and preserves Ethernet
connection by ignoring non-fatal PCIE errors.
CVSS Score
7.8
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid deadlock in fs reclaim with page writeback
Ext4 has a filesystem wide lock protecting ext4_writepages() calls to
avoid races with switching of journalled data flag or inode format. This
lock can however cause a deadlock like:
CPU0 CPU1
ext4_writepages()
percpu_down_read(sbi->s_writepages_rwsem);
ext4_change_inode_journal_flag()
percpu_down_write(sbi->s_writepages_rwsem);
- blocks, all readers block from now on
ext4_do_writepages()
ext4_init_io_end()
kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)
fs_reclaim frees dentry...
dentry_unlink_inode()
iput() - last ref =>
iput_final() - inode dirty =>
write_inode_now()...
ext4_writepages() tries to acquire sbi->s_writepages_rwsem
and blocks forever
Make sure we cannot recurse into filesystem reclaim from writeback code
to avoid the deadlock.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Pointer may be dereferenced
Klocwork tool reported pointer 'rport' returned from call to function
fc_bsg_to_rport() may be NULL and will be dereferenced.
Add a fix to validate rport before dereferencing.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: prevent soft lockup while flush writes
Currently, there is no limit for raid1/raid10 plugged bio. While flushing
writes, raid1 has cond_resched() while raid10 doesn't, and too many
writes can cause soft lockup.
Follow up soft lockup can be triggered easily with writeback test for
raid10 with ramdisks:
watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]
Call Trace:
<TASK>
call_rcu+0x16/0x20
put_object+0x41/0x80
__delete_object+0x50/0x90
delete_object_full+0x2b/0x40
kmemleak_free+0x46/0xa0
slab_free_freelist_hook.constprop.0+0xed/0x1a0
kmem_cache_free+0xfd/0x300
mempool_free_slab+0x1f/0x30
mempool_free+0x3a/0x100
bio_free+0x59/0x80
bio_put+0xcf/0x2c0
free_r10bio+0xbf/0xf0
raid_end_bio_io+0x78/0xb0
one_write_done+0x8a/0xa0
raid10_end_write_request+0x1b4/0x430
bio_endio+0x175/0x320
brd_submit_bio+0x3b9/0x9b7 [brd]
__submit_bio+0x69/0xe0
submit_bio_noacct_nocheck+0x1e6/0x5a0
submit_bio_noacct+0x38c/0x7e0
flush_pending_writes+0xf0/0x240
raid10d+0xac/0x1ed0
Fix the problem by adding cond_resched() to raid10 like what raid1 did.
Note that unlimited plugged bio still need to be optimized, for example,
in the case of lots of dirty pages writeback, this will take lots of
memory and io will spend a long time in plug, hence io latency is bad.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix calltrace warning in amddrm_buddy_fini
The following call trace is observed when removing the amdgpu driver, which
is caused by that BOs allocated for psp are not freed until removing.
[61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy]
[61811.450577] Call Trace:
[61811.450577] <TASK>
[61811.450579] amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu]
[61811.450728] amdgpu_ttm_fini+0x207/0x290 [amdgpu]
[61811.450870] amdgpu_bo_fini+0x27/0xa0 [amdgpu]
[61811.451012] gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu]
[61811.451166] amdgpu_device_fini_sw+0x117/0x520 [amdgpu]
[61811.451306] amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
[61811.451447] devm_drm_dev_init_release+0x4d/0x80 [drm]
[61811.451466] devm_action_release+0x15/0x20
[61811.451469] release_nodes+0x40/0xb0
[61811.451471] devres_release_all+0x9b/0xd0
[61811.451473] __device_release_driver+0x1bb/0x2a0
[61811.451476] driver_detach+0xf3/0x140
[61811.451479] bus_remove_driver+0x6c/0xf0
[61811.451481] driver_unregister+0x31/0x60
[61811.451483] pci_unregister_driver+0x40/0x90
[61811.451486] amdgpu_exit+0x15/0x447 [amdgpu]
For smu v13_0_2, if the GPU supports xgmi, refer to
commit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"),
it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing,
which makes all devices in hive list have hw reset but no resume except the
basic ip blocks, then other ip blocks will not call .hw_fini according to
ip_block.status.hw.
Since psp_free_shared_bufs just includes some software operations, so move
it to psp_sw_fini.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: Fix use after free for wext
Key information in wext.connect is not reset on (re)connect and can hold
data from a previous connection.
Reset key data to avoid that drivers or mac80211 incorrectly detect a
WEP connection request and access the freed or already reused memory.
Additionally optimize cfg80211_sme_connect() and avoid an useless
schedule of conn_work.
CVSS Score
7.8
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
bpf: make sure skb->len != 0 when redirecting to a tunneling device
syzkaller managed to trigger another case where skb->len == 0
when we enter __dev_queue_xmit:
WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]
WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295
Call Trace:
dev_queue_xmit+0x17/0x20 net/core/dev.c:4406
__bpf_tx_skb net/core/filter.c:2115 [inline]
__bpf_redirect_no_mac net/core/filter.c:2140 [inline]
__bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163
____bpf_clone_redirect net/core/filter.c:2447 [inline]
bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419
bpf_prog_48159a89cb4a9a16+0x59/0x5e
bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline]
__bpf_prog_run include/linux/filter.h:596 [inline]
bpf_prog_run include/linux/filter.h:603 [inline]
bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402
bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170
bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648
__sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005
__do_sys_bpf kernel/bpf/syscall.c:5091 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5089 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089
do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48
entry_SYSCALL_64_after_hwframe+0x61/0xc6
The reproducer doesn't really reproduce outside of syzkaller
environment, so I'm taking a guess here. It looks like we
do generate correct ETH_HLEN-sized packet, but we redirect
the packet to the tunneling device. Before we do so, we
__skb_pull l2 header and arrive again at skb->len == 0.
Doesn't seem like we can do anything better than having
an explicit check after __skb_pull?
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
drm/meson: remove drm bridges at aggregate driver unbind time
drm bridges added by meson_encoder_hdmi_init and meson_encoder_cvbs_init
were not manually removed at module unload time, which caused dangling
references to freed memory to remain linked in the global bridge_list.
When loading the driver modules back in, the same functions would again
call drm_bridge_add, and when traversing the global bridge_list, would
end up peeking into freed memory.
Once again KASAN revealed the problem:
[ +0.000095] =============================================================
[ +0.000008] BUG: KASAN: use-after-free in __list_add_valid+0x9c/0x120
[ +0.000018] Read of size 8 at addr ffff00003da291f0 by task modprobe/2483
[ +0.000018] CPU: 3 PID: 2483 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1
[ +0.000011] Hardware name: Hardkernel ODROID-N2Plus (DT)
[ +0.000008] Call trace:
[ +0.000006] dump_backtrace+0x1ec/0x280
[ +0.000012] show_stack+0x24/0x80
[ +0.000008] dump_stack_lvl+0x98/0xd4
[ +0.000011] print_address_description.constprop.0+0x80/0x520
[ +0.000011] print_report+0x128/0x260
[ +0.000008] kasan_report+0xb8/0xfc
[ +0.000008] __asan_report_load8_noabort+0x3c/0x50
[ +0.000009] __list_add_valid+0x9c/0x120
[ +0.000009] drm_bridge_add+0x6c/0x104 [drm]
[ +0.000165] dw_hdmi_probe+0x1900/0x2360 [dw_hdmi]
[ +0.000022] meson_dw_hdmi_bind+0x520/0x814 [meson_dw_hdmi]
[ +0.000014] component_bind+0x174/0x520
[ +0.000012] component_bind_all+0x1a8/0x38c
[ +0.000010] meson_drv_bind_master+0x5e8/0xb74 [meson_drm]
[ +0.000032] meson_drv_bind+0x20/0x2c [meson_drm]
[ +0.000027] try_to_bring_up_aggregate_device+0x19c/0x390
[ +0.000010] component_master_add_with_match+0x1c8/0x284
[ +0.000009] meson_drv_probe+0x274/0x280 [meson_drm]
[ +0.000026] platform_probe+0xd0/0x220
[ +0.000009] really_probe+0x3ac/0xa80
[ +0.000009] __driver_probe_device+0x1f8/0x400
[ +0.000009] driver_probe_device+0x68/0x1b0
[ +0.000009] __driver_attach+0x20c/0x480
[ +0.000008] bus_for_each_dev+0x114/0x1b0
[ +0.000009] driver_attach+0x48/0x64
[ +0.000008] bus_add_driver+0x390/0x564
[ +0.000009] driver_register+0x1a8/0x3e4
[ +0.000009] __platform_driver_register+0x6c/0x94
[ +0.000008] meson_drm_platform_driver_init+0x3c/0x1000 [meson_drm]
[ +0.000027] do_one_initcall+0xc4/0x2b0
[ +0.000011] do_init_module+0x154/0x570
[ +0.000011] load_module+0x1a78/0x1ea4
[ +0.000008] __do_sys_init_module+0x184/0x1cc
[ +0.000009] __arm64_sys_init_module+0x78/0xb0
[ +0.000009] invoke_syscall+0x74/0x260
[ +0.000009] el0_svc_common.constprop.0+0xcc/0x260
[ +0.000008] do_el0_svc+0x50/0x70
[ +0.000007] el0_svc+0x68/0x1a0
[ +0.000012] el0t_64_sync_handler+0x11c/0x150
[ +0.000008] el0t_64_sync+0x18c/0x190
[ +0.000016] Allocated by task 879:
[ +0.000008] kasan_save_stack+0x2c/0x5c
[ +0.000011] __kasan_kmalloc+0x90/0xd0
[ +0.000007] __kmalloc+0x278/0x4a0
[ +0.000011] mpi_resize+0x13c/0x1d0
[ +0.000011] mpi_powm+0xd24/0x1570
[ +0.000009] rsa_enc+0x1a4/0x30c
[ +0.000009] pkcs1pad_verify+0x3f0/0x580
[ +0.000009] public_key_verify_signature+0x7a8/0xba4
[ +0.000010] public_key_verify_signature_2+0x40/0x60
[ +0.000008] verify_signature+0xb4/0x114
[ +0.000008] pkcs7_validate_trust_one.constprop.0+0x3b8/0x574
[ +0.000009] pkcs7_validate_trust+0xb8/0x15c
[ +0.000008] verify_pkcs7_message_sig+0xec/0x1b0
[ +0.000012] verify_pkcs7_signature+0x78/0xac
[ +0.000007] mod_verify_sig+0x110/0x190
[ +0.000009] module_sig_check+0x114/0x1e0
[ +0.000009] load_module+0xa0/0x1ea4
[ +0.000008] __do_sys_init_module+0x184/0x1cc
[ +0.000008] __arm64_sys_init_module+0x78/0xb0
[ +0.000008] invoke_syscall+0x74/0x260
[ +0.000009] el0_svc_common.constprop.0+0x1a8/0x260
[ +0.000008] do_el0_svc+0x50/0x70
[ +0.000007] el0_svc+0x68/0x1a0
[ +0.000009] el0t_64_sync_handler+0x11c/0x150
[ +0.000009] el0t_64
---truncated---
CVSS Score
7.8
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
xen/gntdev: Prevent leaking grants
Prior to this commit, if a grant mapping operation failed partially,
some of the entries in the map_ops array would be invalid, whereas all
of the entries in the kmap_ops array would be valid. This in turn would
cause the following logic in gntdev_map_grant_pages to become invalid:
for (i = 0; i < map->count; i++) {
if (map->map_ops[i].status == GNTST_okay) {
map->unmap_ops[i].handle = map->map_ops[i].handle;
if (!use_ptemod)
alloced++;
}
if (use_ptemod) {
if (map->kmap_ops[i].status == GNTST_okay) {
if (map->map_ops[i].status == GNTST_okay)
alloced++;
map->kunmap_ops[i].handle = map->kmap_ops[i].handle;
}
}
}
...
atomic_add(alloced, &map->live_grants);
Assume that use_ptemod is true (i.e., the domain mapping the granted
pages is a paravirtualized domain). In the code excerpt above, note that
the "alloced" variable is only incremented when both kmap_ops[i].status
and map_ops[i].status are set to GNTST_okay (i.e., both mapping
operations are successful). However, as also noted above, there are
cases where a grant mapping operation fails partially, breaking the
assumption of the code excerpt above.
The aforementioned causes map->live_grants to be incorrectly set. In
some cases, all of the map_ops mappings fail, but all of the kmap_ops
mappings succeed, meaning that live_grants may remain zero. This in turn
makes it impossible to unmap the successfully grant-mapped pages pointed
to by kmap_ops, because unmap_grant_pages has the following snippet of
code at its beginning:
if (atomic_read(&map->live_grants) == 0)
return; /* Nothing to do */
In other cases where only some of the map_ops mappings fail but all
kmap_ops mappings succeed, live_grants is made positive, but when the
user requests unmapping the grant-mapped pages, __unmap_grant_pages_done
will then make map->live_grants negative, because the latter function
does not check if all of the pages that were requested to be unmapped
were actually unmapped, and the same function unconditionally subtracts
"data->count" (i.e., a value that can be greater than map->live_grants)
from map->live_grants. The side effects of a negative live_grants value
have not been studied.
The net effect of all of this is that grant references are leaked in one
of the above conditions. In Qubes OS v4.1 (which uses Xen's grant
mechanism extensively for X11 GUI isolation), this issue manifests
itself with warning messages like the following to be printed out by the
Linux kernel in the VM that had granted pages (that contain X11 GUI
window data) to dom0: "g.e. 0x1234 still pending", especially after the
user rapidly resizes GUI VM windows (causing some grant-mapping
operations to partially or completely fail, due to the fact that the VM
unshares some of the pages as part of the window resizing, making the
pages impossible to grant-map from dom0).
The fix for this issue involves counting all successful map_ops and
kmap_ops mappings separately, and then adding the sum to live_grants.
During unmapping, only the number of successfully unmapped grants is
subtracted from live_grants. The code is also modified to check for
negative live_grants values after the subtraction and warn the user.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-15