| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
PCI/AER: Fix NULL pointer access by aer_info
The kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info->xxx
will result in kernel panic. Fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface
When performing reset tests and encountering abnormal card drop issues
that lead to a kernel crash, it is necessary to perform a null check
before releasing resources to avoid attempting to release a null pointer.
<4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT)
<4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth]
<4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
<4>[ 29.158162] pc : klist_remove+0x90/0x158
<4>[ 29.158174] lr : klist_remove+0x88/0x158
<4>[ 29.158180] sp : ffffffc0846b3c00
<4>[ 29.158185] pmr_save: 000000e0
<4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058
<4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0
<4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290
<4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781
<4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428
<4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018
<4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000
<4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d
<4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e
<4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c
<4>[ 29.158285] Call trace:
<4>[ 29.158290] klist_remove+0x90/0x158
<4>[ 29.158298] device_release_driver_internal+0x20c/0x268
<4>[ 29.158308] device_release_driver+0x1c/0x30
<4>[ 29.158316] usb_driver_release_interface+0x70/0x88
<4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)]
<4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)]
<4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)]
<4>[ 29.158430] process_scheduled_works+0x258/0x4e8
<4>[ 29.158441] worker_thread+0x300/0x428
<4>[ 29.158448] kthread+0x108/0x1d0
<4>[ 29.158455] ret_from_fork+0x10/0x20
<0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297)
<4>[ 29.158474] ---[ end trace 0000000000000000 ]---
<0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception
<2>[ 29.167144] SMP: stopping secondary CPUs
<4>[ 29.167158] ------------[ cut here ]------------ |
| In the Linux kernel, the following vulnerability has been resolved:
s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump
Do not block PCI config accesses through pci_cfg_access_lock() when
executing the s390 variant of PCI error recovery: Acquire just
device_lock() instead of pci_dev_lock() as powerpc's EEH and
generig PCI AER processing do.
During error recovery testing a pair of tasks was reported to be hung:
mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working
INFO: task kmcheck:72 blocked for more than 122 seconds.
Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000
Call Trace:
[<000000065256f030>] __schedule+0x2a0/0x590
[<000000065256f356>] schedule+0x36/0xe0
[<000000065256f572>] schedule_preempt_disabled+0x22/0x30
[<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8
[<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core]
[<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core]
[<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398
[<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0
INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds.
Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000
Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]
Call Trace:
[<000000065256f030>] __schedule+0x2a0/0x590
[<000000065256f356>] schedule+0x36/0xe0
[<0000000652172e28>] pci_wait_cfg+0x80/0xe8
[<0000000652172f94>] pci_cfg_access_lock+0x74/0x88
[<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core]
[<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core]
[<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core]
[<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168
[<0000000652513212>] devlink_health_report+0x19a/0x230
[<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]
No kernel log of the exact same error with an upstream kernel is
available - but the very same deadlock situation can be constructed there,
too:
- task: kmcheck
mlx5_unload_one() tries to acquire devlink lock while the PCI error
recovery code has set pdev->block_cfg_access by way of
pci_cfg_access_lock()
- task: kworker
mlx5_crdump_collect() tries to set block_cfg_access through
pci_cfg_access_lock() while devlink_health_report() had acquired
the devlink lock.
A similar deadlock situation can be reproduced by requesting a
crdump with
> devlink health dump show pci/<BDF> reporter fw_fatal
while PCI error recovery is executed on the same <BDF> physical function
by mlx5_core's pci_error_handlers. On s390 this can be injected with
> zpcictl --reset-fw <BDF>
Tests with this patch failed to reproduce that second deadlock situation,
the devlink command is rejected with "kernel answers: Permission denied" -
and we get a kernel log message of:
mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5
because the config read of VSC_SEMAPHORE is rejected by the underlying
hardware.
Two prior attempts to address this issue have been discussed and
ultimately rejected [see link], with the primary argument that s390's
implementation of PCI error recovery is imposing restrictions that
neither powerpc's EEH nor PCI AER handling need. Tests show that PCI
error recovery on s390 is running to completion even without blocking
access to PCI config space. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix invalid probe error return value
After DME Link Startup, the error return value is set to the MIPI UniPro
GenericErrorCode which can be 0 (SUCCESS) or 1 (FAILURE). Upon failure
during driver probe, the error code 1 is propagated back to the driver
probe function which must return a negative value to indicate an error,
but 1 is not negative, so the probe is considered to be successful even
though it failed. Subsequently, removing the driver results in an oops
because it is not in a valid state.
This happens because none of the callers of ufshcd_init() expect a
non-negative error code.
Fix the return value and documentation to match actual usage. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: wavefront: Fix integer overflow in sample size validation
The wavefront_send_sample() function has an integer overflow issue
when validating sample size. The header->size field is u32 but gets
cast to int for comparison with dev->freemem
Fix by using unsigned comparison to avoid integer overflow. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: fix use-after-free caused by uec->work
The delayed work uec->work is scheduled in gaokun_ucsi_probe()
but never properly canceled in gaokun_ucsi_remove(). This creates
use-after-free scenarios where the ucsi and gaokun_ucsi structure
are freed after ucsi_destroy() completes execution, while the
gaokun_ucsi_register_worker() might be either currently executing
or still pending in the work queue. The already-freed gaokun_ucsi
or ucsi structure may then be accessed.
Furthermore, the race window is 3 seconds, which is sufficiently
long to make this bug easily reproducible. The following is the
trace captured by KASAN:
==================================================================
BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630
Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0
...
Call trace:
show_stack+0x18/0x24 (C)
dump_stack_lvl+0x78/0x90
print_report+0x114/0x580
kasan_report+0xa4/0xf0
__asan_report_store8_noabort+0x20/0x2c
__run_timers+0x5ec/0x630
run_timer_softirq+0xe8/0x1cc
handle_softirqs+0x294/0x720
__do_softirq+0x14/0x20
____do_softirq+0x10/0x1c
call_on_irq_stack+0x30/0x48
do_softirq_own_stack+0x1c/0x28
__irq_exit_rcu+0x27c/0x364
irq_exit_rcu+0x10/0x1c
el1_interrupt+0x40/0x60
el1h_64_irq_handler+0x18/0x24
el1h_64_irq+0x6c/0x70
arch_local_irq_enable+0x4/0x8 (P)
do_idle+0x334/0x458
cpu_startup_entry+0x60/0x70
rest_init+0x158/0x174
start_kernel+0x2f8/0x394
__primary_switched+0x8c/0x94
Allocated by task 72 on cpu 0 at 27.510341s:
kasan_save_stack+0x2c/0x54
kasan_save_track+0x24/0x5c
kasan_save_alloc_info+0x40/0x54
__kasan_kmalloc+0xa0/0xb8
__kmalloc_node_track_caller_noprof+0x1c0/0x588
devm_kmalloc+0x7c/0x1c8
gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8
really_probe+0x17c/0x5b8
__driver_probe_device+0x158/0x2c4
driver_probe_device+0x10c/0x264
__device_attach_driver+0x168/0x2d0
bus_for_each_drv+0x100/0x188
__device_attach+0x174/0x368
device_initial_probe+0x14/0x20
bus_probe_device+0x120/0x150
device_add+0xb3c/0x10fc
__auxiliary_device_add+0x88/0x130
...
Freed by task 73 on cpu 1 at 28.910627s:
kasan_save_stack+0x2c/0x54
kasan_save_track+0x24/0x5c
__kasan_save_free_info+0x4c/0x74
__kasan_slab_free+0x60/0x8c
kfree+0xd4/0x410
devres_release_all+0x140/0x1f0
device_unbind_cleanup+0x20/0x190
device_release_driver_internal+0x344/0x460
device_release_driver+0x18/0x24
bus_remove_device+0x198/0x274
device_del+0x310/0xa84
...
The buggy address belongs to the object at ffff00000ec28c00
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 200 bytes inside of
freed 512-byte region
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28
head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff)
page_type: f5(slab)
raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
================================================================
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
drm/sysfb: Do not dereference NULL pointer in plane reset
The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not
deref that pointer, but forward NULL to the other plane-reset helpers.
Clears plane->state to NULL.
v2:
- fix typo in commit description (Javier) |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop
In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen
and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes
that the parent qdisc will enqueue the current packet. However, this
assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent
qdisc stops enqueuing current packet, leaving the tree qlen/backlog
accounting inconsistent. This mismatch can lead to a NULL dereference
(e.g., when the parent Qdisc is qfq_qdisc).
This patch computes the qlen/backlog delta in a more robust way by
observing the difference before and after the series of cake_drop()
calls, and then compensates the qdisc tree accounting if cake_enqueue()
returns NET_XMIT_CN.
To ensure correct compensation when ACK thinning is enabled, a new
variable is introduced to keep qlen unchanged. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: stratix10-svc: fix bug in saving controller data
Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They
both are of the same data and overrides each other. This resulted in the
rmmod of the svc driver to fail and throw a kernel panic for kthread_stop
and fifo free. |
| In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix general protection fault in __smc_diag_dump
The syzbot report a crash:
Oops: general protection fault, probably for non-canonical address 0xfbd5a5d5a0000003: 0000 [#1] SMP KASAN NOPTI
KASAN: maybe wild-memory-access in range [0xdead4ead00000018-0xdead4ead0000001f]
CPU: 1 UID: 0 PID: 6949 Comm: syz.0.335 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:smc_diag_msg_common_fill net/smc/smc_diag.c:44 [inline]
RIP: 0010:__smc_diag_dump.constprop.0+0x3ca/0x2550 net/smc/smc_diag.c:89
Call Trace:
<TASK>
smc_diag_dump_proto+0x26d/0x420 net/smc/smc_diag.c:217
smc_diag_dump+0x27/0x90 net/smc/smc_diag.c:234
netlink_dump+0x539/0xd30 net/netlink/af_netlink.c:2327
__netlink_dump_start+0x6d6/0x990 net/netlink/af_netlink.c:2442
netlink_dump_start include/linux/netlink.h:341 [inline]
smc_diag_handler_dump+0x1f9/0x240 net/smc/smc_diag.c:251
__sock_diag_cmd net/core/sock_diag.c:249 [inline]
sock_diag_rcv_msg+0x438/0x790 net/core/sock_diag.c:285
netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552
netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
netlink_unicast+0x5a7/0x870 net/netlink/af_netlink.c:1346
netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896
sock_sendmsg_nosec net/socket.c:714 [inline]
__sock_sendmsg net/socket.c:729 [inline]
____sys_sendmsg+0xa95/0xc70 net/socket.c:2614
___sys_sendmsg+0x134/0x1d0 net/socket.c:2668
__sys_sendmsg+0x16d/0x220 net/socket.c:2700
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4e0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
The process like this:
(CPU1) | (CPU2)
---------------------------------|-------------------------------
inet_create() |
// init clcsock to NULL |
sk = sk_alloc() |
|
// unexpectedly change clcsock |
inet_init_csk_locks() |
|
// add sk to hash table |
smc_inet_init_sock() |
smc_sk_init() |
smc_hash_sk() |
| // traverse the hash table
| smc_diag_dump_proto
| __smc_diag_dump()
| // visit wrong clcsock
| smc_diag_msg_common_fill()
// alloc clcsock |
smc_create_clcsk |
sock_create_kern |
With CONFIG_DEBUG_LOCK_ALLOC=y, the smc->clcsock is unexpectedly changed
in inet_init_csk_locks(). The INET_PROTOSW_ICSK flag is no need by smc,
just remove it.
After removing the INET_PROTOSW_ICSK flag, this patch alse revert
commit 6fd27ea183c2 ("net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC")
to avoid casting smc_sock to inet_connection_sock. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: renesas_usbhs: Fix synchronous external abort on unbind
A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is
executed after the configuration sequence described above:
modprobe usb_f_ecm
modprobe libcomposite
modprobe configfs
cd /sys/kernel/config/usb_gadget
mkdir -p g1
cd g1
echo "0x1d6b" > idVendor
echo "0x0104" > idProduct
mkdir -p strings/0x409
echo "0123456789" > strings/0x409/serialnumber
echo "Renesas." > strings/0x409/manufacturer
echo "Ethernet Gadget" > strings/0x409/product
mkdir -p functions/ecm.usb0
mkdir -p configs/c.1
mkdir -p configs/c.1/strings/0x409
echo "ECM" > configs/c.1/strings/0x409/configuration
if [ ! -L configs/c.1/ecm.usb0 ]; then
ln -s functions/ecm.usb0 configs/c.1
fi
echo 11e20000.usb > UDC
echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind
The displayed trace is as follows:
Internal error: synchronous external abort: 0000000096000010 [#1] SMP
CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT
Tainted: [M]=MACHINE_CHECK
Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT)
pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs]
lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs]
sp : ffff8000838b3920
x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000
x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810
x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000
x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020
x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344
x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000
x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418
x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d
x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000
x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80
Call trace:
usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P)
usbhsg_pullup+0x4c/0x7c [renesas_usbhs]
usb_gadget_disconnect_locked+0x48/0xd4
gadget_unbind_driver+0x44/0x114
device_remove+0x4c/0x80
device_release_driver_internal+0x1c8/0x224
device_release_driver+0x18/0x24
bus_remove_device+0xcc/0x10c
device_del+0x14c/0x404
usb_del_gadget+0x88/0xc0
usb_del_gadget_udc+0x18/0x30
usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs]
usbhs_mod_remove+0x20/0x30 [renesas_usbhs]
usbhs_remove+0x98/0xdc [renesas_usbhs]
platform_remove+0x20/0x30
device_remove+0x4c/0x80
device_release_driver_internal+0x1c8/0x224
device_driver_detach+0x18/0x24
unbind_store+0xb4/0xb8
drv_attr_store+0x24/0x38
sysfs_kf_write+0x7c/0x94
kernfs_fop_write_iter+0x128/0x1b8
vfs_write+0x2ac/0x350
ksys_write+0x68/0xfc
__arm64_sys_write+0x1c/0x28
invoke_syscall+0x48/0x110
el0_svc_common.constprop.0+0xc0/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x34/0xf0
el0t_64_sync_handler+0xa0/0xe4
el0t_64_sync+0x198/0x19c
Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021)
---[ end trace 0000000000000000 ]---
note: sh[188] exited with irqs disabled
note: sh[188] exited with preempt_count 1
The issue occurs because usbhs_sys_function_pullup(), which accesses the IP
registers, is executed after the USBHS clocks have been disabled. The
problem is reproducible on the Renesas RZ/G3S SoC starting with the
addition of module stop in the clock enable/disable APIs. With module stop
functionality enabled, a bus error is expected if a master accesses a
module whose clock has been stopped and module stop activated.
Disable the IP clocks at the end of remove. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86/amd/pmc: Add support for Van Gogh SoC
The ROG Xbox Ally (non-X) SoC features a similar architecture to the
Steam Deck. While the Steam Deck supports S3 (s2idle causes a crash),
this support was dropped by the Xbox Ally which only S0ix suspend.
Since the handler is missing here, this causes the device to not suspend
and the AMD GPU driver to crash while trying to resume afterwards due to
a power hang. |
| In the Linux kernel, the following vulnerability has been resolved:
comedi: c6xdigio: Fix invalid PNP driver unregistration
The Comedi low-level driver "c6xdigio" seems to be for a parallel port
connected device. When the Comedi core calls the driver's Comedi
"attach" handler `c6xdigio_attach()` to configure a Comedi to use this
driver, it tries to enable the parallel port PNP resources by
registering a PNP driver with `pnp_register_driver()`, but ignores the
return value. (The `struct pnp_driver` it uses has only the `name` and
`id_table` members filled in.) The driver's Comedi "detach" handler
`c6xdigio_detach()` unconditionally unregisters the PNP driver with
`pnp_unregister_driver()`.
It is possible for `c6xdigio_attach()` to return an error before it
calls `pnp_register_driver()` and it is possible for the call to
`pnp_register_driver()` to return an error (that is ignored). In both
cases, the driver should not be calling `pnp_unregister_driver()` as it
does in `c6xdigio_detach()`. (Note that `c6xdigio_detach()` will be
called by the Comedi core if `c6xdigio_attach()` returns an error, or if
the Comedi core decides to detach the Comedi device from the driver for
some other reason.)
The unconditional call to `pnp_unregister_driver()` without a previous
successful call to `pnp_register_driver()` will cause
`driver_unregister()` to issue a warning "Unexpected driver
unregister!". This was detected by Syzbot [1].
Also, the PNP driver registration and unregistration should be done at
module init and exit time, respectively, not when attaching or detaching
Comedi devices to the driver. (There might be more than one Comedi
device being attached to the driver, although that is unlikely.)
Change the driver to do the PNP driver registration at module init time,
and the unregistration at module exit time. Since `c6xdigio_detach()`
now only calls `comedi_legacy_detach()`, remove the function and change
the Comedi driver "detach" handler to `comedi_legacy_detach`.
-------------------------------------------
[1] Syzbot sample crash report:
Unexpected driver unregister!
WARNING: CPU: 0 PID: 5970 at drivers/base/driver.c:273 driver_unregister drivers/base/driver.c:273 [inline]
WARNING: CPU: 0 PID: 5970 at drivers/base/driver.c:273 driver_unregister+0x90/0xb0 drivers/base/driver.c:270
Modules linked in:
CPU: 0 UID: 0 PID: 5970 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
RIP: 0010:driver_unregister drivers/base/driver.c:273 [inline]
RIP: 0010:driver_unregister+0x90/0xb0 drivers/base/driver.c:270
Code: 48 89 ef e8 c2 e6 82 fc 48 89 df e8 3a 93 ff ff 5b 5d e9 c3 6d d9 fb e8 be 6d d9 fb 90 48 c7 c7 e0 f8 1f 8c e8 51 a2 97 fb 90 <0f> 0b 90 90 5b 5d e9 a5 6d d9 fb e8 e0 f4 41 fc eb 94 e8 d9 f4 41
RSP: 0018:ffffc9000373f9a0 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffffffff8ff24720 RCX: ffffffff817b6ee8
RDX: ffff88807c932480 RSI: ffffffff817b6ef5 RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff8ff24660
R13: dffffc0000000000 R14: 0000000000000000 R15: ffff88814cca0000
FS: 000055556dab1500(0000) GS:ffff8881249d9000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055f77f285cd0 CR3: 000000007d871000 CR4: 00000000003526f0
Call Trace:
<TASK>
comedi_device_detach_locked+0x12f/0xa50 drivers/comedi/drivers.c:207
comedi_device_detach+0x67/0xb0 drivers/comedi/drivers.c:215
comedi_device_attach+0x43d/0x900 drivers/comedi/drivers.c:1011
do_devconfig_ioctl+0x1b1/0x710 drivers/comedi/comedi_fops.c:872
comedi_unlocked_ioctl+0x165d/0x2f00 drivers/comedi/comedi_fops.c:2178
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_sys
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: mte: Do not warn if the page is already tagged in copy_highpage()
The arm64 copy_highpage() assumes that the destination page is newly
allocated and not MTE-tagged (PG_mte_tagged unset) and warns
accordingly. However, following commit 060913999d7a ("mm: migrate:
support poisoned recover from migrate folio"), folio_mc_copy() is called
before __folio_migrate_mapping(). If the latter fails (-EAGAIN), the
copy will be done again to the same destination page. Since
copy_highpage() already set the PG_mte_tagged flag, this second copy
will warn.
Replace the WARN_ON_ONCE(page already tagged) in the arm64
copy_highpage() with a comment. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/mellanox: mlxbf-pmc: add sysfs_attr_init() to count_clock init
The lock-related debug logic (CONFIG_LOCK_STAT) in the kernel is noting
the following warning when the BlueField-3 SOC is booted:
BUG: key ffff00008a3402a8 has not been registered!
------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(1)
WARNING: CPU: 4 PID: 592 at kernel/locking/lockdep.c:4801 lockdep_init_map_type+0x1d4/0x2a0
<snip>
Call trace:
lockdep_init_map_type+0x1d4/0x2a0
__kernfs_create_file+0x84/0x140
sysfs_add_file_mode_ns+0xcc/0x1cc
internal_create_group+0x110/0x3d4
internal_create_groups.part.0+0x54/0xcc
sysfs_create_groups+0x24/0x40
device_add+0x6e8/0x93c
device_register+0x28/0x40
__hwmon_device_register+0x4b0/0x8a0
devm_hwmon_device_register_with_groups+0x7c/0xe0
mlxbf_pmc_probe+0x1e8/0x3e0 [mlxbf_pmc]
platform_probe+0x70/0x110
The mlxbf_pmc driver must call sysfs_attr_init() during the
initialization of the "count_clock" data structure to avoid
this warning. |
| In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()
The syzbot reported issue in hfsplus_delete_cat():
[ 70.682285][ T9333] =====================================================
[ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220
[ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220
[ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0
[ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310
[ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810
[ 70.685447][ T9333] do_rmdir+0x964/0xea0
[ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0
[ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0
[ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0
[ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.687646][ T9333]
[ 70.687856][ T9333] Uninit was stored to memory at:
[ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0
[ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800
[ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600
[ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70
[ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0
[ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30
[ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0
[ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0
[ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0
[ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.692773][ T9333]
[ 70.692990][ T9333] Uninit was stored to memory at:
[ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0
[ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800
[ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700
[ 70.694911][ T9333] mount_bdev+0x37b/0x530
[ 70.695320][ T9333] hfsplus_mount+0x4d/0x60
[ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0
[ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0
[ 70.696588][ T9333] do_new_mount+0x73e/0x1630
[ 70.697013][ T9333] path_mount+0x6e3/0x1eb0
[ 70.697425][ T9333] __se_sys_mount+0x733/0x830
[ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150
[ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0
[ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0
[ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.699730][ T9333]
[ 70.699946][ T9333] Uninit was created at:
[ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60
[ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0
[ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0
[ 70.701774][ T9333] allocate_slab+0x30e/0x1390
[ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0
[ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20
[ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0
[ 70.703598][ T9333] alloc_inode+0x82/0x490
[ 70.703984][ T9333] iget_locked+0x22e/0x1320
[ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0
[ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0
[ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700
[ 70.705776][ T9333] mount_bdev+0x37b/0x530
[ 70.706171][ T9333] hfsplus_mount+0x4d/0x60
[ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0
[ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0
[ 70.707444][ T9333] do_new_mount+0x73e/0x1630
[ 70.707865][ T9333] path_mount+0x6e3/0x1eb0
[ 70.708270][ T9333] __se_sys_mount+0x733/0x830
[ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150
[ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0
[ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0
[ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.710611][ T9333]
[ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17
[ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 70.712490][ T9333] =====================================================
[ 70.713085][ T9333] Disabling lock debugging due to kernel taint
[ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ...
[ 70.714159][ T9333]
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
net: dsa: microchip: Don't free uninitialized ksz_irq
If something goes wrong at setup, ksz_irq_free() can be called on
uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It
leads to freeing uninitialized IRQ numbers and/or domains.
Use dsa_switch_for_each_user_port_continue_reverse() in the error path
to iterate only over the fully initialized ports. |
| In the Linux kernel, the following vulnerability has been resolved:
can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data
The URB received in gs_usb_receive_bulk_callback() contains a struct
gs_host_frame. The length of the data after the header depends on the
gs_host_frame hf::flags and the active device features (e.g. time
stamping).
Introduce a new function gs_usb_get_minimum_length() and check that we have
at least received the required amount of data before accessing it. Only
copy the data to that skb that has actually been received.
[mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()] |
| In the Linux kernel, the following vulnerability has been resolved:
slab: Avoid race on slab->obj_exts in alloc_slab_obj_exts
If two competing threads enter alloc_slab_obj_exts() and one of them
fails to allocate the object extension vector, it might override the
valid slab->obj_exts allocated by the other thread with
OBJEXTS_ALLOC_FAIL. This will cause the thread that lost this race and
expects a valid pointer to dereference a NULL pointer later on.
Update slab->obj_exts atomically using cmpxchg() to avoid
slab->obj_exts overrides by racing threads.
Thanks for Vlastimil and Suren's help with debugging. |
| In the Linux kernel, the following vulnerability has been resolved:
can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header
The driver expects to receive a struct gs_host_frame in
gs_usb_receive_bulk_callback().
Use struct_group to describe the header of the struct gs_host_frame and
check that we have at least received the header before accessing any
members of it.
To resubmit the URB, do not dereference the pointer chain
"dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since
"urb->context" contains "parent", it is always defined, while "dev" is not
defined if the URB it too short. |
