Security Vulnerabilities
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
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds()
This patch fixes a stack-out-of-bounds read in brcmfmac that occurs
when 'buf' that is not null-terminated is passed as an argument of
strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware
version string by memcpy() in brcmf_fil_iovar_data_get().
The patch ensures buf is null-terminated.
Found by a modified version of syzkaller.
[ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3
[ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 47.601565][ T1897] ==================================================================
[ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0
[ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897
[ 47.604336][ T1897]
[ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131
[ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event
[ 47.607453][ T1897] Call Trace:
[ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1
[ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334
[ 47.609009][ T1897] ? strsep+0x1b2/0x1f0
[ 47.609434][ T1897] ? strsep+0x1b2/0x1f0
[ 47.609863][ T1897] kasan_report.cold+0x83/0xdf
[ 47.610366][ T1897] ? strsep+0x1b2/0x1f0
[ 47.610882][ T1897] strsep+0x1b2/0x1f0
[ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0
[ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40
[ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100
[ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0
[ 47.614704][ T1897] ? find_held_lock+0x2d/0x110
[ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260
[ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0
[ 47.616288][ T1897] brcmf_attach+0x246/0xd40
[ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0
[ 47.617280][ T1897] ? kmemdup+0x43/0x50
[ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690
[ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470
[ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760
[ 47.619429][ T1897] ? usb_probe_device+0x250/0x250
[ 47.619950][ T1897] really_probe+0x205/0xb70
[ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0
[ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.622209][ T1897] driver_probe_device+0x4e/0x150
[ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0
[ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0
[ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30
[ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160
[ 47.625437][ T1897] __device_attach+0x23f/0x3a0
[ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0
[ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0
[ 47.627057][ T1897] bus_probe_device+0x1da/0x290
[ 47.627557][ T1897] device_add+0xb7b/0x1eb0
[ 47.628027][ T1897] ? wait_for_completion+0x290/0x290
[ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0
[ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0
[ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0
[ 47.630385][ T1897] usb_probe_device+0xbb/0x250
[ 47.630927][ T1897] ? usb_suspend+0x590/0x590
[ 47.631397][ T1897] really_probe+0x205/0xb70
[ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0
[ 47.633002][
---truncated---
CVSS Score
7.8
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: fix race in sock_map_free()
sock_map_free() calls release_sock(sk) without owning a reference
on the socket. This can cause use-after-free as syzbot found [1]
Jakub Sitnicki already took care of a similar issue
in sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash:
Synchronize delete from bucket list on map free")
[1]
refcount_t: decrement hit 0; leaking memory.
WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
Modules linked in:
CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: events_unbound bpf_map_free_deferred
RIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ff
RSP: 0018:ffffc9000456fb60 EFLAGS: 00010246
RAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0
RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000
RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5
R10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004
R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcf
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__refcount_dec include/linux/refcount.h:344 [inline]
refcount_dec include/linux/refcount.h:359 [inline]
__sock_put include/net/sock.h:779 [inline]
tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092
release_sock+0xaf/0x1c0 net/core/sock.c:3468
sock_map_free+0x219/0x2c0 net/core/sock_map.c:356
process_one_work+0x81c/0xd10 kernel/workqueue.c:2289
worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
kthread+0x266/0x300 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
CVSS Score
4.7
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Make .remove and .shutdown HW shutdown consistent
Drivers' .remove and .shutdown callbacks are executed on different code
paths. The former is called when a device is removed from the bus, while
the latter is called at system shutdown time to quiesce the device.
This means that some overlap exists between the two, because both have to
take care of properly shutting down the hardware. But currently the logic
used in these two callbacks isn't consistent in msm drivers, which could
lead to kernel panic.
For example, on .remove the component is deleted and its .unbind callback
leads to the hardware being shutdown but only if the DRM device has been
marked as registered.
That check doesn't exist in the .shutdown logic and this can lead to the
driver calling drm_atomic_helper_shutdown() for a DRM device that hasn't
been properly initialized.
A situation like this can happen if drivers for expected sub-devices fail
to probe, since the .bind callback will never be executed. If that is the
case, drm_atomic_helper_shutdown() will attempt to take mutexes that are
only initialized if drm_mode_config_init() is called during a device bind.
This bug was attempted to be fixed in commit 623f279c7781 ("drm/msm: fix
shutdown hook in case GPU components failed to bind"), but unfortunately
it still happens in some cases as the one mentioned above, i.e:
systemd-shutdown[1]: Powering off.
kvm: exiting hardware virtualization
platform wifi-firmware.0: Removing from iommu group 12
platform video-firmware.0: Removing from iommu group 10
------------[ cut here ]------------
WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:317 drm_modeset_lock_all_ctx+0x3c4/0x3d0
...
Hardware name: Google CoachZ (rev3+) (DT)
pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_modeset_lock_all_ctx+0x3c4/0x3d0
lr : drm_modeset_lock_all_ctx+0x48/0x3d0
sp : ffff80000805bb80
x29: ffff80000805bb80 x28: ffff327c00128000 x27: 0000000000000000
x26: 0000000000000000 x25: 0000000000000001 x24: ffffc95d820ec030
x23: ffff327c00bbd090 x22: ffffc95d8215eca0 x21: ffff327c039c5800
x20: ffff327c039c5988 x19: ffff80000805bbe8 x18: 0000000000000034
x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000
x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
x2 : ffff327c00128000 x1 : 0000000000000000 x0 : ffff327c039c59b0
Call trace:
drm_modeset_lock_all_ctx+0x3c4/0x3d0
drm_atomic_helper_shutdown+0x70/0x134
msm_drv_shutdown+0x30/0x40
platform_shutdown+0x28/0x40
device_shutdown+0x148/0x350
kernel_power_off+0x38/0x80
__do_sys_reboot+0x288/0x2c0
__arm64_sys_reboot+0x28/0x34
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0x44/0xec
do_el0_svc+0x2c/0xc0
el0_svc+0x2c/0x84
el0t_64_sync_handler+0x11c/0x150
el0t_64_sync+0x18c/0x190
---[ end trace 0000000000000000 ]---
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
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
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=000000010eab1000
[0000000000000018] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
...
Hardware name: Google CoachZ (rev3+) (DT)
pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ww_mutex_lock+0x28/0x32c
lr : drm_modeset_lock_all_ctx+0x1b0/0x3d0
sp : ffff80000805bb50
x29: ffff80000805bb50 x28: ffff327c00128000 x27: 0000000000000000
x26: 00000
---truncated---
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid()
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_hda_connector_mode_valid,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_dvo_connector_mode_valid,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_hdmi_connector_mode_valid,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpci: fix of node refcount leak in tcpci_register_port()
I got the following report while doing device(mt6370-tcpc) load
test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled:
OF: ERROR: memory leak, expected refcount 1 instead of 2,
of_node_get()/of_node_put() unbalanced - destroy cset entry:
attach overlay node /i2c/pmic@34/tcpc/connector
The 'fwnode' set in tcpci_parse_config() which is called
in tcpci_register_port(), its node refcount is increased
in device_get_named_child_node(). It needs be put while
exiting, so call fwnode_handle_put() in the error path of
tcpci_register_port() and in tcpci_unregister_port() to
avoid leak.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci-mtk: fix leakage of shared hcd when fail to set wakeup irq
Can not set the @shared_hcd to NULL before decrease the usage count
by usb_put_hcd(), this will cause the shared hcd not released.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix double free on tx path.
We see kernel crashes and lockups and KASAN errors related to ax210
firmware crashes. One of the KASAN dumps pointed at the tx path,
and it appears there is indeed a way to double-free an skb.
If iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the
method will be freed. But, in case where we build TSO skb buffer,
the skb may also be freed in error case. So, return 0 in that particular
error case and do cleanup manually.
BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90
iwlwifi 0000:06:00.0: 0x00000000 | tsf hi
Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650
CPU: 4 PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5
iwlwifi 0000:06:00.0: 0x00000000 | time gp1
Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019
Call Trace:
<TASK>
dump_stack_lvl+0x55/0x6d
print_report.cold.12+0xf2/0x684
iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2
? __list_del_entry_valid+0x12/0x90
kasan_report+0x8b/0x180
iwlwifi 0000:06:00.0: 0x00000001 | uCode revision type
? __list_del_entry_valid+0x12/0x90
__list_del_entry_valid+0x12/0x90
iwlwifi 0000:06:00.0: 0x00000048 | uCode version major
tcp_update_skb_after_send+0x5d/0x170
__tcp_transmit_skb+0xb61/0x15c0
iwlwifi 0000:06:00.0: 0xDAA05125 | uCode version minor
? __tcp_select_window+0x490/0x490
iwlwifi 0000:06:00.0: 0x00000420 | hw version
? trace_kmalloc_node+0x29/0xd0
? __kmalloc_node_track_caller+0x12a/0x260
? memset+0x1f/0x40
? __build_skb_around+0x125/0x150
? __alloc_skb+0x1d4/0x220
? skb_zerocopy_clone+0x55/0x230
iwlwifi 0000:06:00.0: 0x00489002 | board version
? kmalloc_reserve+0x80/0x80
? rcu_read_lock_bh_held+0x60/0xb0
tcp_write_xmit+0x3f1/0x24d0
iwlwifi 0000:06:00.0: 0x034E001C | hcmd
? __check_object_size+0x180/0x350
iwlwifi 0000:06:00.0: 0x24020000 | isr0
tcp_sendmsg_locked+0x8a9/0x1520
iwlwifi 0000:06:00.0: 0x01400000 | isr1
? tcp_sendpage+0x50/0x50
iwlwifi 0000:06:00.0: 0x48F0000A | isr2
? lock_release+0xb9/0x400
? tcp_sendmsg+0x14/0x40
iwlwifi 0000:06:00.0: 0x00C3080C | isr3
? lock_downgrade+0x390/0x390
? do_raw_spin_lock+0x114/0x1d0
iwlwifi 0000:06:00.0: 0x00200000 | isr4
? rwlock_bug.part.2+0x50/0x50
iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id
? rwlock_bug.part.2+0x50/0x50
? lockdep_hardirqs_on_prepare+0xe/0x200
iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event
? __local_bh_enable_ip+0x87/0xe0
? inet_send_prepare+0x220/0x220
iwlwifi 0000:06:00.0: 0x000000C4 | l2p_control
tcp_sendmsg+0x22/0x40
sock_sendmsg+0x5f/0x70
iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration
__sys_sendto+0x19d/0x250
iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid
? __ia32_sys_getpeername+0x40/0x40
iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match
? rcu_read_lock_held_common+0x12/0x50
? rcu_read_lock_sched_held+0x5a/0xd0
? rcu_read_lock_bh_held+0xb0/0xb0
? rcu_read_lock_sched_held+0x5a/0xd0
? rcu_read_lock_sched_held+0x5a/0xd0
? lock_release+0xb9/0x400
? lock_downgrade+0x390/0x390
? ktime_get+0x64/0x130
? ktime_get+0x8d/0x130
? rcu_read_lock_held_common+0x12/0x50
? rcu_read_lock_sched_held+0x5a/0xd0
? rcu_read_lock_held_common+0x12/0x50
? rcu_read_lock_sched_held+0x5a/0xd0
? rcu_read_lock_bh_held+0xb0/0xb0
? rcu_read_lock_bh_held+0xb0/0xb0
__x64_sys_sendto+0x6f/0x80
do_syscall_64+0x34/0xb0
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f1d126e4531
Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0 75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89
RSP: 002b:00007ffe21a679d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 000000000000ffdc RCX: 00007f1d126e4531
RDX: 0000000000010000 RSI: 000000000374acf0 RDI: 0000000000000014
RBP: 00007ffe21a67ac0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R
---truncated---
CVSS Score
7.8
EPSS Score
0.0
Published
2025-09-15
In the Linux kernel, the following vulnerability has been resolved:
memory: of: Fix refcount leak bug in of_get_ddr_timings()
We should add the of_node_put() when breaking out of
for_each_child_of_node() as it will automatically increase
and decrease the refcount.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-15