Debian: Security Vulnerabilities
In the Linux kernel, the following vulnerability has been resolved:
objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()
If dib8000_set_dds()'s call to dib8000_read32() returns zero, the result
is a divide-by-zero. Prevent that from happening.
Fixes the following warning with an UBSAN kernel:
drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()
CVSS Score
5.5
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in kerberos authentication
Setting sess->user = NULL was introduced to fix the dangling pointer
created by ksmbd_free_user. However, it is possible another thread could
be operating on the session and make use of sess->user after it has been
passed to ksmbd_free_user but before sess->user is set to NULL.
CVSS Score
7.8
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid
or uid buffers. Comparing ACPIID_LEN against a total string length doesn't
take into account the lengths of individual hid and uid buffers so the
check is insufficient in some cases. For example if the length of hid
string is 4 and the length of the uid string is 260, the length of str
will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer
which size is 256.
The same applies to the hid string with length 13 and uid string with
length 250.
Check the length of hid and uid strings separately to prevent
buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score
7.8
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
dm-bufio: don't schedule in atomic context
A BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP and
try_verify_in_tasklet are enabled.
[ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421
[ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4
[ 129.444740][ T934] preempt_count: 201, expected: 0
[ 129.444756][ T934] RCU nest depth: 0, expected: 0
[ 129.444781][ T934] Preemption disabled at:
[ 129.444789][ T934] [<ffffffd816231900>] shrink_work+0x21c/0x248
[ 129.445167][ T934] kernel BUG at kernel/sched/walt/walt_debug.c:16!
[ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
[ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0
[ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8
[ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT)
[ 129.447373][ T934] Workqueue: dm_bufio_cache shrink_work
[ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 129.447406][ T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug]
[ 129.447435][ T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c
[ 129.447451][ T934] sp : ffffffc0843dbc90
[ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b
[ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68
[ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900
[ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030
[ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358
[ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003
[ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400
[ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8
[ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0
[ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000
[ 129.447647][ T934] Call trace:
[ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6]
[ 129.447681][ T934] __might_resched+0x190/0x1a8
[ 129.447694][ T934] shrink_work+0x180/0x248
[ 129.447706][ T934] process_one_work+0x260/0x624
[ 129.447718][ T934] worker_thread+0x28c/0x454
[ 129.447729][ T934] kthread+0x118/0x158
[ 129.447742][ T934] ret_from_fork+0x10/0x20
[ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000)
[ 129.447772][ T934] ---[ end trace 0000000000000000 ]---
dm_bufio_lock will call spin_lock_bh when try_verify_in_tasklet
is enabled, and __scan will be called in atomic context.
CVSS Score
7.8
EPSS Score
0.003
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
arm64: errata: Add missing sentinels to Spectre-BHB MIDR arrays
Commit a5951389e58d ("arm64: errata: Add newer ARM cores to the
spectre_bhb_loop_affected() lists") added some additional CPUs to the
Spectre-BHB workaround, including some new arrays for designs that
require new 'k' values for the workaround to be effective.
Unfortunately, the new arrays omitted the sentinel entry and so
is_midr_in_range_list() will walk off the end when it doesn't find a
match. With UBSAN enabled, this leads to a crash during boot when
is_midr_in_range_list() is inlined (which was more common prior to
c8c2647e69be ("arm64: Make _midr_in_range_list() an exported
function")):
| Internal error: aarch64 BRK: 00000000f2000001 [#1] PREEMPT SMP
| pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : spectre_bhb_loop_affected+0x28/0x30
| lr : is_spectre_bhb_affected+0x170/0x190
| [...]
| Call trace:
| spectre_bhb_loop_affected+0x28/0x30
| update_cpu_capabilities+0xc0/0x184
| init_cpu_features+0x188/0x1a4
| cpuinfo_store_boot_cpu+0x4c/0x60
| smp_prepare_boot_cpu+0x38/0x54
| start_kernel+0x8c/0x478
| __primary_switched+0xc8/0xd4
| Code: 6b09011f 54000061 52801080 d65f03c0 (d4200020)
| ---[ end trace 0000000000000000 ]---
| Kernel panic - not syncing: aarch64 BRK: Fatal exception
Add the missing sentinel entries.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()
Nouveau is mostly designed in a way that it's expected that fences only
ever get signaled through nouveau_fence_signal(). However, in at least
one other place, nouveau_fence_done(), can signal fences, too. If that
happens (race) a signaled fence remains in the pending list for a while,
until it gets removed by nouveau_fence_update().
Should nouveau_fence_context_kill() run in the meantime, this would be
a bug because the function would attempt to set an error code on an
already signaled fence.
Have nouveau_fence_context_kill() check for a fence being signaled.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
btrfs: adjust subpage bit start based on sectorsize
When running machines with 64k page size and a 16k nodesize we started
seeing tree log corruption in production. This turned out to be because
we were not writing out dirty blocks sometimes, so this in fact affects
all metadata writes.
When writing out a subpage EB we scan the subpage bitmap for a dirty
range. If the range isn't dirty we do
bit_start++;
to move onto the next bit. The problem is the bitmap is based on the
number of sectors that an EB has. So in this case, we have a 64k
pagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4
bits for every node. With a 64k page size we end up with 4 nodes per
page.
To make this easier this is how everything looks
[0 16k 32k 48k ] logical address
[0 4 8 12 ] radix tree offset
[ 64k page ] folio
[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers
[ | | | | | | | | | | | | | | | | ] bitmap
Now we use all of our addressing based on fs_info->sectorsize_bits, so
as you can see the above our 16k eb->start turns into radix entry 4.
When we find a dirty range for our eb, we correctly do bit_start +=
sectors_per_node, because if we start at bit 0, the next bit for the
next eb is 4, to correspond to eb->start 16k.
However if our range is clean, we will do bit_start++, which will now
put us offset from our radix tree entries.
In our case, assume that the first time we check the bitmap the block is
not dirty, we increment bit_start so now it == 1, and then we loop
around and check again. This time it is dirty, and we go to find that
start using the following equation
start = folio_start + bit_start * fs_info->sectorsize;
so in the case above, eb->start 0 is now dirty, and we calculate start
as
0 + 1 * fs_info->sectorsize = 4096
4096 >> 12 = 1
Now we're looking up the radix tree for 1, and we won't find an eb.
What's worse is now we're using bit_start == 1, so we do bit_start +=
sectors_per_node, which is now 5. If that eb is dirty we will run into
the same thing, we will look at an offset that is not populated in the
radix tree, and now we're skipping the writeout of dirty extent buffers.
The best fix for this is to not use sectorsize_bits to address nodes,
but that's a larger change. Since this is a fs corruption problem fix
it simply by always using sectors_per_node to increment the start bit.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
sch_htb: make htb_qlen_notify() idempotent
htb_qlen_notify() always deactivates the HTB class and in fact could
trigger a warning if it is already deactivated. Therefore, it is not
idempotent and not friendly to its callers, like fq_codel_dequeue().
Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers'
life.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx poll
Use spin_lock_irqsave and spin_unlock_irqrestore instead of spin_lock
and spin_unlock in mtk_star_emac driver to avoid spinlock recursion
occurrence that can happen when enabling the DMA interrupts again in
rx/tx poll.
```
BUG: spinlock recursion on CPU#0, swapper/0/0
lock: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0,
.owner_cpu: 0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
6.15.0-rc2-next-20250417-00001-gf6a27738686c-dirty #28 PREEMPT
Hardware name: MediaTek MT8365 Open Platform EVK (DT)
Call trace:
show_stack+0x18/0x24 (C)
dump_stack_lvl+0x60/0x80
dump_stack+0x18/0x24
spin_dump+0x78/0x88
do_raw_spin_lock+0x11c/0x120
_raw_spin_lock+0x20/0x2c
mtk_star_handle_irq+0xc0/0x22c [mtk_star_emac]
__handle_irq_event_percpu+0x48/0x140
handle_irq_event+0x4c/0xb0
handle_fasteoi_irq+0xa0/0x1bc
handle_irq_desc+0x34/0x58
generic_handle_domain_irq+0x1c/0x28
gic_handle_irq+0x4c/0x120
do_interrupt_handler+0x50/0x84
el1_interrupt+0x34/0x68
el1h_64_irq_handler+0x18/0x24
el1h_64_irq+0x6c/0x70
regmap_mmio_read32le+0xc/0x20 (P)
_regmap_bus_reg_read+0x6c/0xac
_regmap_read+0x60/0xdc
regmap_read+0x4c/0x80
mtk_star_rx_poll+0x2f4/0x39c [mtk_star_emac]
__napi_poll+0x38/0x188
net_rx_action+0x164/0x2c0
handle_softirqs+0x100/0x244
__do_softirq+0x14/0x20
____do_softirq+0x10/0x20
call_on_irq_stack+0x24/0x64
do_softirq_own_stack+0x1c/0x40
__irq_exit_rcu+0xd4/0x10c
irq_exit_rcu+0x10/0x1c
el1_interrupt+0x38/0x68
el1h_64_irq_handler+0x18/0x24
el1h_64_irq+0x6c/0x70
cpuidle_enter_state+0xac/0x320 (P)
cpuidle_enter+0x38/0x50
do_idle+0x1e4/0x260
cpu_startup_entry+0x34/0x3c
rest_init+0xdc/0xe0
console_on_rootfs+0x0/0x6c
__primary_switched+0x88/0x90
```
CVSS Score
5.5
EPSS Score
0.0
Published
2025-05-20
In the Linux kernel, the following vulnerability has been resolved:
vxlan: vnifilter: Fix unlocked deletion of default FDB entry
When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB
entry associated with the default remote (assuming one was configured)
is deleted without holding the hash lock. This is wrong and will result
in a warning [1] being generated by the lockdep annotation that was
added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").
Reproducer:
# ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1
# bridge vni add vni 10010 remote 198.51.100.1 dev vx0
# bridge vni del vni 10010 dev vx0
Fix by acquiring the hash lock before the deletion and releasing it
afterwards. Blame the original commit that introduced the issue rather
than the one that exposed it.
[1]
WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0
[...]
RIP: 0010:vxlan_find_mac+0x17f/0x1a0
[...]
Call Trace:
<TASK>
__vxlan_fdb_delete+0xbe/0x560
vxlan_vni_delete_group+0x2ba/0x940
vxlan_vni_del.isra.0+0x15f/0x580
vxlan_process_vni_filter+0x38b/0x7b0
vxlan_vnifilter_process+0x3bb/0x510
rtnetlink_rcv_msg+0x2f7/0xb70
netlink_rcv_skb+0x131/0x360
netlink_unicast+0x426/0x710
netlink_sendmsg+0x75a/0xc20
__sock_sendmsg+0xc1/0x150
____sys_sendmsg+0x5aa/0x7b0
___sys_sendmsg+0xfc/0x180
__sys_sendmsg+0x121/0x1b0
do_syscall_64+0xbb/0x1d0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
CVSS Score
7.8
EPSS Score
0.0
Published
2025-05-20