Debian: >> Debian Linux Security Vulnerabilities
In the Linux kernel, the following vulnerability has been resolved:
net_sched: qfq: Fix double list add in class with netem as child qdisc
As described in Gerrard's report [1], there are use cases where a netem
child qdisc will make the parent qdisc's enqueue callback reentrant.
In the case of qfq, there won't be a UAF, but the code will add the same
classifier to the list twice, which will cause memory corruption.
This patch checks whether the class was already added to the agg->active
list (cl_is_active) before doing the addition to cater for the reentrant
case.
[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
CVSS Score
7.8
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
net_sched: ets: Fix double list add in class with netem as child qdisc
As described in Gerrard's report [1], there are use cases where a netem
child qdisc will make the parent qdisc's enqueue callback reentrant.
In the case of ets, there won't be a UAF, but the code will add the same
classifier to the list twice, which will cause memory corruption.
In addition to checking for qlen being zero, this patch checks whether
the class was already added to the active_list (cl_is_active) before
doing the addition to cater for the reentrant case.
[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
CVSS Score
7.8
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
wifi: plfxlc: Remove erroneous assert in plfxlc_mac_release
plfxlc_mac_release() asserts that mac->lock is held. This assertion is
incorrect, because even if it was possible, it would not be the valid
behaviour. The function is used when probe fails or after the device is
disconnected. In both cases mac->lock can not be held as the driver is
not working with the device at the moment. All functions that use mac->lock
unlock it just after it was held. There is also no need to hold mac->lock
for plfxlc_mac_release() itself, as mac data is not affected, except for
mac->flags, which is modified atomically.
This bug leads to the following warning:
================================================================
WARNING: CPU: 0 PID: 127 at drivers/net/wireless/purelifi/plfxlc/mac.c:106 plfxlc_mac_release+0x7d/0xa0
Modules linked in:
CPU: 0 PID: 127 Comm: kworker/0:2 Not tainted 6.1.124-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: usb_hub_wq hub_event
RIP: 0010:plfxlc_mac_release+0x7d/0xa0 drivers/net/wireless/purelifi/plfxlc/mac.c:106
Call Trace:
<TASK>
probe+0x941/0xbd0 drivers/net/wireless/purelifi/plfxlc/usb.c:694
usb_probe_interface+0x5c0/0xaf0 drivers/usb/core/driver.c:396
really_probe+0x2ab/0xcb0 drivers/base/dd.c:639
__driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785
driver_probe_device+0x50/0x420 drivers/base/dd.c:815
__device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943
bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429
__device_attach+0x359/0x570 drivers/base/dd.c:1015
bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489
device_add+0xb48/0xfd0 drivers/base/core.c:3696
usb_set_configuration+0x19dd/0x2020 drivers/usb/core/message.c:2165
usb_generic_driver_probe+0x84/0x140 drivers/usb/core/generic.c:238
usb_probe_device+0x130/0x260 drivers/usb/core/driver.c:293
really_probe+0x2ab/0xcb0 drivers/base/dd.c:639
__driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785
driver_probe_device+0x50/0x420 drivers/base/dd.c:815
__device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943
bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429
__device_attach+0x359/0x570 drivers/base/dd.c:1015
bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489
device_add+0xb48/0xfd0 drivers/base/core.c:3696
usb_new_device+0xbdd/0x18f0 drivers/usb/core/hub.c:2620
hub_port_connect drivers/usb/core/hub.c:5477 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5617 [inline]
port_event drivers/usb/core/hub.c:5773 [inline]
hub_event+0x2efe/0x5730 drivers/usb/core/hub.c:5855
process_one_work+0x8a9/0x11d0 kernel/workqueue.c:2292
worker_thread+0xa47/0x1200 kernel/workqueue.c:2439
kthread+0x28d/0x320 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
</TASK>
================================================================
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs
On Qualcomm chipsets not all GPIOs are wakeup capable. Those GPIOs do not
have a corresponding MPM pin and should not be handled inside the MPM
driver. The IRQ domain hierarchy is always applied, so it's required to
explicitly disconnect the hierarchy for those. The pinctrl-msm driver marks
these with GPIO_NO_WAKE_IRQ. qcom-pdc has a check for this, but
irq-qcom-mpm is currently missing the check. This is causing crashes when
setting up interrupts for non-wake GPIOs:
root@rb1:~# gpiomon -c gpiochip1 10
irq: IRQ159: trimming hierarchy from :soc@0:interrupt-controller@f200000-1
Unable to handle kernel paging request at virtual address ffff8000a1dc3820
Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT)
pc : mpm_set_type+0x80/0xcc
lr : mpm_set_type+0x5c/0xcc
Call trace:
mpm_set_type+0x80/0xcc (P)
qcom_mpm_set_type+0x64/0x158
irq_chip_set_type_parent+0x20/0x38
msm_gpio_irq_set_type+0x50/0x530
__irq_set_trigger+0x60/0x184
__setup_irq+0x304/0x6bc
request_threaded_irq+0xc8/0x19c
edge_detector_setup+0x260/0x364
linereq_create+0x420/0x5a8
gpio_ioctl+0x2d4/0x6c0
Fix this by copying the check for GPIO_NO_WAKE_IRQ from qcom-pdc.c, so that
MPM is removed entirely from the hierarchy for non-wake GPIOs.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix slab-use-after-free in hdcp
The HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connector
objects without incrementing the kref reference counts. When using a
USB-C dock, and the dock is unplugged, the corresponding
amdgpu_dm_connector objects are freed, creating dangling pointers in the
HDCP code. When the dock is plugged back, the dangling pointers are
dereferenced, resulting in a slab-use-after-free:
[ 66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu]
[ 66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10
[ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233
[ 66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024
[ 66.776186] Workqueue: events event_property_validate [amdgpu]
[ 66.776494] Call Trace:
[ 66.776496] <TASK>
[ 66.776497] dump_stack_lvl+0x70/0xa0
[ 66.776504] print_report+0x175/0x555
[ 66.776507] ? __virt_addr_valid+0x243/0x450
[ 66.776510] ? kasan_complete_mode_report_info+0x66/0x1c0
[ 66.776515] kasan_report+0xeb/0x1c0
[ 66.776518] ? event_property_validate+0x42f/0x6c0 [amdgpu]
[ 66.776819] ? event_property_validate+0x42f/0x6c0 [amdgpu]
[ 66.777121] __asan_report_load4_noabort+0x14/0x20
[ 66.777124] event_property_validate+0x42f/0x6c0 [amdgpu]
[ 66.777342] ? __lock_acquire+0x6b40/0x6b40
[ 66.777347] ? enable_assr+0x250/0x250 [amdgpu]
[ 66.777571] process_one_work+0x86b/0x1510
[ 66.777575] ? pwq_dec_nr_in_flight+0xcf0/0xcf0
[ 66.777578] ? assign_work+0x16b/0x280
[ 66.777580] ? lock_is_held_type+0xa3/0x130
[ 66.777583] worker_thread+0x5c0/0xfa0
[ 66.777587] ? process_one_work+0x1510/0x1510
[ 66.777588] kthread+0x3a2/0x840
[ 66.777591] ? kthread_is_per_cpu+0xd0/0xd0
[ 66.777594] ? trace_hardirqs_on+0x4f/0x60
[ 66.777597] ? _raw_spin_unlock_irq+0x27/0x60
[ 66.777599] ? calculate_sigpending+0x77/0xa0
[ 66.777602] ? kthread_is_per_cpu+0xd0/0xd0
[ 66.777605] ret_from_fork+0x40/0x90
[ 66.777607] ? kthread_is_per_cpu+0xd0/0xd0
[ 66.777609] ret_from_fork_asm+0x11/0x20
[ 66.777614] </TASK>
[ 66.777643] Allocated by task 10:
[ 66.777646] kasan_save_stack+0x39/0x60
[ 66.777649] kasan_save_track+0x14/0x40
[ 66.777652] kasan_save_alloc_info+0x37/0x50
[ 66.777655] __kasan_kmalloc+0xbb/0xc0
[ 66.777658] __kmalloc_cache_noprof+0x1c8/0x4b0
[ 66.777661] dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu]
[ 66.777880] drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper]
[ 66.777892] drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper]
[ 66.777901] drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper]
[ 66.777909] drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper]
[ 66.777917] process_one_work+0x86b/0x1510
[ 66.777919] worker_thread+0x5c0/0xfa0
[ 66.777922] kthread+0x3a2/0x840
[ 66.777925] ret_from_fork+0x40/0x90
[ 66.777927] ret_from_fork_asm+0x11/0x20
[ 66.777932] Freed by task 1713:
[ 66.777935] kasan_save_stack+0x39/0x60
[ 66.777938] kasan_save_track+0x14/0x40
[ 66.777940] kasan_save_free_info+0x3b/0x60
[ 66.777944] __kasan_slab_free+0x52/0x70
[ 66.777946] kfree+0x13f/0x4b0
[ 66.777949] dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu]
[ 66.778179] drm_connector_free+0x7d/0xb0
[ 66.778184] drm_mode_object_put.part.0+0xee/0x160
[ 66.778188] drm_mode_object_put+0x37/0x50
[ 66.778191] drm_atomic_state_default_clear+0x220/0xd60
[ 66.778194] __drm_atomic_state_free+0x16e/0x2a0
[ 66.778197] drm_mode_atomic_ioctl+0x15ed/0x2ba0
[ 66.778200] drm_ioctl_kernel+0x17a/0x310
[ 66.778203] drm_ioctl+0x584/0xd10
[ 66.778206] amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu]
[ 66.778375] __x64_sys_ioctl+0x139/0x1a0
[ 66.778378] x64_sys_call+0xee7/0xfb0
[ 66.778381]
---truncated---
CVSS Score
7.8
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Balance device refcount when destroying devices
Using device_find_child() to lookup the proper SCMI device to destroy
causes an unbalance in device refcount, since device_find_child() calls an
implicit get_device(): this, in turns, inhibits the call of the provided
release methods upon devices destruction.
As a consequence, one of the structures that is not freed properly upon
destruction is the internal struct device_private dev->p populated by the
drivers subsystem core.
KMemleak detects this situation since loading/unloding some SCMI driver
causes related devices to be created/destroyed without calling any
device_release method.
unreferenced object 0xffff00000f583800 (size 512):
comm "insmod", pid 227, jiffies 4294912190
hex dump (first 32 bytes):
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6......
backtrace (crc 114e2eed):
kmemleak_alloc+0xbc/0xd8
__kmalloc_cache_noprof+0x2dc/0x398
device_add+0x954/0x12d0
device_register+0x28/0x40
__scmi_device_create.part.0+0x1bc/0x380
scmi_device_create+0x2d0/0x390
scmi_create_protocol_devices+0x74/0xf8
scmi_device_request_notifier+0x1f8/0x2a8
notifier_call_chain+0x110/0x3b0
blocking_notifier_call_chain+0x70/0xb0
scmi_driver_register+0x350/0x7f0
0xffff80000a3b3038
do_one_initcall+0x12c/0x730
do_init_module+0x1dc/0x640
load_module+0x4b20/0x5b70
init_module_from_file+0xec/0x158
$ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0
device_add+0x954/0x12d0:
kmalloc_noprof at include/linux/slab.h:901
(inlined by) kzalloc_noprof at include/linux/slab.h:1037
(inlined by) device_private_init at drivers/base/core.c:3510
(inlined by) device_add at drivers/base/core.c:3561
Balance device refcount by issuing a put_device() on devices found via
device_find_child().
CVSS Score
5.5
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
mtd: inftlcore: Add error check for inftl_read_oob()
In INFTL_findwriteunit(), the return value of inftl_read_oob()
need to be checked. A proper implementation can be
found in INFTL_deleteblock(). The status will be set as
SECTOR_IGNORE to break from the while-loop correctly
if the inftl_read_oob() fails.
CVSS Score
7.8
EPSS Score
0.0
Published
2025-05-20
setuptools is a package that allows users to download, build, install, upgrade, and uninstall Python packages. A path traversal vulnerability in `PackageIndex` is present in setuptools prior to version 78.1.1. An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to remote code execution depending on the context. Version 78.1.1 fixes the issue.
CVSS Score
8.8
EPSS Score
0.001
Published
2025-05-17
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc
As described in Gerrard's report [1], we have a UAF case when an hfsc class
has a netem child qdisc. The crux of the issue is that hfsc is assuming
that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted
the class in the vttree or eltree (which is not true for the netem
duplicate case).
This patch checks the n_active class variable to make sure that the code
won't insert the class in the vttree or eltree twice, catering for the
reentrant case.
[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
CVSS Score
7.8
EPSS Score
0.0
Published
2025-05-16
In the Linux kernel, the following vulnerability has been resolved:
ASoC: ops: Consistently treat platform_max as control value
This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in
snd_soc_put_volsw() by +min"), and makes some additional related
updates.
There are two ways the platform_max could be interpreted; the maximum
register value, or the maximum value the control can be set to. The
patch moved from treating the value as a control value to a register
one. When the patch was applied it was technically correct as
snd_soc_limit_volume() also used the register interpretation. However,
even then most of the other usages treated platform_max as a
control value, and snd_soc_limit_volume() has since been updated to
also do so in commit fb9ad24485087 ("ASoC: ops: add correct range
check for limiting volume"). That patch however, missed updating
snd_soc_put_volsw() back to the control interpretation, and fixing
snd_soc_info_volsw_range(). The control interpretation makes more
sense as limiting is typically done from the machine driver, so it is
appropriate to use the customer facing representation rather than the
internal codec representation. Update all the code to consistently use
this interpretation of platform_max.
Finally, also add some comments to the soc_mixer_control struct to
hopefully avoid further patches switching between the two approaches.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-05-09