ALT-PU-2024-18467-2
Package kernel-image-un-def updated to version 6.6.21-alt1 for branch sisyphus in task 342200.
Closed vulnerabilities
Modified: 2025-08-19
BDU:2024-03682
Уязвимость функции mptcp_sk_clone_init() в модуле net/mptcp/protocol.c реализации протокола Multipath TCP (MPTCP) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-04
BDU:2024-03684
Уязвимость функции btrfs_get_root_ref() в модуле fs/btrfs/disk-io.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-03685
Уязвимость функции gtp_init() в модуле drivers/net/gtp.c реализации протокола GPRS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-03686
Уязвимость функции hci_error_reset() в модуле net/bluetooth/hci_core.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-05-21
BDU:2024-03757
Уязвимость функции filemap_cachestat() в модуле mm/filemap.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-05-21
BDU:2024-03772
Уязвимость функции tls_do_decryption() в модуле net/tls/tls_sw.c реализации протокола TLS ядра операционной системы Linux, позволяющая нарушителю оказать вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-04137
Уязвимость функции tomoyo_write_control() подсистемы безопасности TOMOYO ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-03-21
BDU:2024-09129
Уязвимость компонента rtas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09130
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09132
Уязвимость компонента fsl-qdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09134
Уязвимость компонентов dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09149
Уязвимость компонента riscv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09150
Уязвимость компонента af_unix ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09185
Уязвимость компонента mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09187
Уязвимость компонента netlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09190
Уязвимость компонентов powerpc/pseries/iommu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09192
Уязвимость компонентов idxd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09193
Уязвимость компонента perf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09194
Уязвимость компонентов fbcon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09196
Уязвимость компонента stmmac ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09198
Уязвимость компонента veth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09199
Уязвимость компонента ip_tunnel ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2025-03-21
BDU:2024-09201
Уязвимость компонента netlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09208
Уязвимость компонента stm32 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-03-21
BDU:2024-09216
Уязвимость компонента iommufd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09217
Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-09802
Уязвимость компонента nl80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-09839
Уязвимость компонентов efi/capsule-loader ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2024-09858
Уязвимость компонента rtnetlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-09983
Уязвимость компонента HDMA ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе
Modified: 2026-01-20
BDU:2024-09992
Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2026-01-20
BDU:2024-09993
Уязвимость компонента hci_event ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-03-21
BDU:2024-09994
Уязвимость компонента bridge ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-11617
Уязвимость функции __lpass_get_dmactl_handle компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-23
BDU:2025-00068
Уязвимость функции dev_get_drvdata() драйвера контроллера Cadence Quad SPI (drivers/spi/spi-cadence-quadspi.c)i ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03085
Уязвимость функции bq27xxx_battery_i2c_remove() модуля drivers/power/supply/bq27xxx_battery_i2c.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13355
Уязвимость компонентов drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-13358
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2026-03-11
BDU:2025-15231
Уязвимость функции tls_do_decryption() (net/tls/tls_sw.c) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
BDU:2026-03536
Уязвимость функции dw_edma_v0_core_write_chunk() модуля drivers/dma/dw-edma/dw-edma-v0-core.c драйвера поддержки движка DMA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-09-18
CVE-2023-52657
In the Linux kernel, the following vulnerability has been resolved: Revert "drm/amd/pm: resolve reboot exception for si oland" This reverts commit e490d60a2f76bff636c68ce4fe34c1b6c34bbd86. This causes hangs on SI when DC is enabled and errors on driver reboot and power off cycles.
- https://git.kernel.org/stable/c/2e443ed55fe3ffb08327b331a9f45e9382413c94
- https://git.kernel.org/stable/c/955558030954b9637b41c97b730f9b38c92ac488
- https://git.kernel.org/stable/c/baac292852c0e347626fb5436916947188e5838f
- https://git.kernel.org/stable/c/c51468ac328d3922747be55507c117e47da813e6
- https://git.kernel.org/stable/c/2e443ed55fe3ffb08327b331a9f45e9382413c94
- https://git.kernel.org/stable/c/955558030954b9637b41c97b730f9b38c92ac488
- https://git.kernel.org/stable/c/baac292852c0e347626fb5436916947188e5838f
- https://git.kernel.org/stable/c/c51468ac328d3922747be55507c117e47da813e6
Modified: 2025-11-04
CVE-2024-26622
In the Linux kernel, the following vulnerability has been resolved: tomoyo: fix UAF write bug in tomoyo_write_control() Since tomoyo_write_control() updates head->write_buf when write() of long lines is requested, we need to fetch head->write_buf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems.
- https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f
- https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815
- https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824
- https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711
- https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc
- https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee
- https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f
- https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815
- https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824
- https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711
- https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc
- https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IVVYSTEVMPYGF6GDSOD44MUXZXAZHOHB/
Modified: 2025-03-13
CVE-2024-26630
In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix folio read-after-free in cache walk In cachestat, we access the folio from the page cache's xarray to compute its page offset, and check for its dirty and writeback flags. However, we do not hold a reference to the folio before performing these actions, which means the folio can concurrently be released and reused as another folio/page/slab. Get around this altogether by just using xarray's existing machinery for the folio page offsets and dirty/writeback states. This changes behavior for tmpfs files to now always report zeroes in their dirty and writeback counters. This is okay as tmpfs doesn't follow conventional writeback cache behavior: its pages get "cleaned" during swapout, after which they're no longer resident etc.
- https://git.kernel.org/stable/c/3a75cb05d53f4a6823a32deb078de1366954a804
- https://git.kernel.org/stable/c/ba60fdf75e89ea762bb617be578dc47f27655117
- https://git.kernel.org/stable/c/fe7e008e0ce728252e4ec652cceebcc62211657c
- https://git.kernel.org/stable/c/3a75cb05d53f4a6823a32deb078de1366954a804
- https://git.kernel.org/stable/c/ba60fdf75e89ea762bb617be578dc47f27655117
- https://git.kernel.org/stable/c/fe7e008e0ce728252e4ec652cceebcc62211657c
Modified: 2025-04-04
CVE-2024-26745
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV
When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due
to NULL pointer exception:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc000000020847ad4
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop
CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12
Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries
NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c
REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+)
MSR: 800000000280b033
- https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051
- https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28
- https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3
- https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf
- https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051
- https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28
- https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3
- https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf
Modified: 2025-03-18
CVE-2024-26746
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Ensure safe user copy of completion record
If CONFIG_HARDENED_USERCOPY is enabled, copying completion record from
event log cache to user triggers a kernel bug.
[ 1987.159822] usercopy: Kernel memory exposure attempt detected from SLUB object 'dsa0' (offset 74, size 31)!
[ 1987.170845] ------------[ cut here ]------------
[ 1987.176086] kernel BUG at mm/usercopy.c:102!
[ 1987.180946] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 1987.186866] CPU: 17 PID: 528 Comm: kworker/17:1 Not tainted 6.8.0-rc2+ #5
[ 1987.194537] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
[ 1987.206405] Workqueue: wq0.0 idxd_evl_fault_work [idxd]
[ 1987.212338] RIP: 0010:usercopy_abort+0x72/0x90
[ 1987.217381] Code: 58 65 9c 50 48 c7 c2 17 85 61 9c 57 48 c7 c7 98 fd 6b 9c 48 0f 44 d6 48 c7 c6 b3 08 62 9c 4c 89 d1 49 0f 44 f3 e8 1e 2e d5 ff <0f> 0b 49 c7 c1 9e 42 61 9c 4c 89 cf 4d 89 c8 eb a9 66 66 2e 0f 1f
[ 1987.238505] RSP: 0018:ff62f5cf20607d60 EFLAGS: 00010246
[ 1987.244423] RAX: 000000000000005f RBX: 000000000000001f RCX: 0000000000000000
[ 1987.252480] RDX: 0000000000000000 RSI: ffffffff9c61429e RDI: 00000000ffffffff
[ 1987.260538] RBP: ff62f5cf20607d78 R08: ff2a6a89ef3fffe8 R09: 00000000fffeffff
[ 1987.268595] R10: ff2a6a89eed00000 R11: 0000000000000003 R12: ff2a66934849c89a
[ 1987.276652] R13: 0000000000000001 R14: ff2a66934849c8b9 R15: ff2a66934849c899
[ 1987.284710] FS: 0000000000000000(0000) GS:ff2a66b22fe40000(0000) knlGS:0000000000000000
[ 1987.293850] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1987.300355] CR2: 00007fe291a37000 CR3: 000000010fbd4005 CR4: 0000000000f71ef0
[ 1987.308413] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1987.316470] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[ 1987.324527] PKRU: 55555554
[ 1987.327622] Call Trace:
[ 1987.330424]
- https://git.kernel.org/stable/c/5e3022ea42e490a36ec6f2cfa6fc603deb0bace4
- https://git.kernel.org/stable/c/bb71e040323175e18c233a9afef32ba14fa64eb7
- https://git.kernel.org/stable/c/d3ea125df37dc37972d581b74a5d3785c3f283ab
- https://git.kernel.org/stable/c/5e3022ea42e490a36ec6f2cfa6fc603deb0bace4
- https://git.kernel.org/stable/c/bb71e040323175e18c233a9afef32ba14fa64eb7
- https://git.kernel.org/stable/c/d3ea125df37dc37972d581b74a5d3785c3f283ab
Modified: 2025-03-18
CVE-2024-26780
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix task hung while purging oob_skb in GC.
syzbot reported a task hung; at the same time, GC was looping infinitely
in list_for_each_entry_safe() for OOB skb. [0]
syzbot demonstrated that the list_for_each_entry_safe() was not actually
safe in this case.
A single skb could have references for multiple sockets. If we free such
a skb in the list_for_each_entry_safe(), the current and next sockets could
be unlinked in a single iteration.
unix_notinflight() uses list_del_init() to unlink the socket, so the
prefetched next socket forms a loop itself and list_for_each_entry_safe()
never stops.
Here, we must use while() and make sure we always fetch the first socket.
[0]:
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 5065 Comm: syz-executor236 Not tainted 6.8.0-rc3-syzkaller-00136-g1f719a2f3fa6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
RIP: 0010:preempt_count arch/x86/include/asm/preempt.h:26 [inline]
RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]
RIP: 0010:__sanitizer_cov_trace_pc+0xd/0x60 kernel/kcov.c:207
Code: cc cc cc cc 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 48 8b 14 25 40 c2 03 00 <65> 8b 05 b4 7c 78 7e a9 00 01 ff 00 48 8b 34 24 74 0f f6 c4 01 74
RSP: 0018:ffffc900033efa58 EFLAGS: 00000283
RAX: ffff88807b077800 RBX: ffff88807b077800 RCX: 1ffffffff27b1189
RDX: ffff88802a5a3b80 RSI: ffffffff8968488d RDI: ffff88807b077f70
RBP: ffffc900033efbb0 R08: 0000000000000001 R09: fffffbfff27a900c
R10: ffffffff93d48067 R11: ffffffff8ae000eb R12: ffff88807b077800
R13: dffffc0000000000 R14: ffff88807b077e40 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000564f4fc1e3a8 CR3: 000000000d57a000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/25236c91b5ab4a26a56ba2e79b8060cf4e047839
- https://git.kernel.org/stable/c/2a3d40b4025fcfe51b04924979f1653993b17669
- https://git.kernel.org/stable/c/36f7371de977f805750748e80279be7e370df85c
- https://git.kernel.org/stable/c/69e0f04460f4037e01e29f0d9675544f62aafca3
- https://git.kernel.org/stable/c/cb8890318dde26fc89c6ea67d6e9070ab50b6e91
- https://git.kernel.org/stable/c/25236c91b5ab4a26a56ba2e79b8060cf4e047839
- https://git.kernel.org/stable/c/2a3d40b4025fcfe51b04924979f1653993b17669
- https://git.kernel.org/stable/c/36f7371de977f805750748e80279be7e370df85c
- https://git.kernel.org/stable/c/69e0f04460f4037e01e29f0d9675544f62aafca3
- https://git.kernel.org/stable/c/cb8890318dde26fc89c6ea67d6e9070ab50b6e91
Modified: 2025-01-07
CVE-2024-26781
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix possible deadlock in subflow diag Syzbot and Eric reported a lockdep splat in the subflow diag: WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted syz-executor.2/24141 is trying to acquire lock: ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 but task is already holding lock: ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&h->lhash2[i].lock){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743 inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261 __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217 inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239 rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316 rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577 ops_init+0x352/0x610 net/core/net_namespace.c:136 __register_pernet_operations net/core/net_namespace.c:1214 [inline] register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283 register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370 rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735 do_one_initcall+0x238/0x830 init/main.c:1236 do_initcall_level+0x157/0x210 init/main.c:1298 do_initcalls+0x3f/0x80 init/main.c:1314 kernel_init_freeable+0x42f/0x5d0 init/main.c:1551 kernel_init+0x1d/0x2a0 init/main.c:1441 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 -> #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_fast include/net/sock.h:1723 [inline] subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28 tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345 inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061 __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263 inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371 netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405 sock_diag_rcv_msg+0xe7/0x410 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 As noted by Eric we can break the lock dependency chain avoid dumping ---truncated---
- https://git.kernel.org/stable/c/70e5b013538d5e4cb421afed431a5fcd2a5d49ee
- https://git.kernel.org/stable/c/cc32ba2fdf3f8b136619fff551f166ba51ec856d
- https://git.kernel.org/stable/c/d487e7ba1bc7444d5f062c4930ef8436c47c7e63
- https://git.kernel.org/stable/c/d6a9608af9a75d13243d217f6ce1e30e57d56ffe
- https://git.kernel.org/stable/c/f27d319df055629480b84b9288a502337b6f2a2e
- https://git.kernel.org/stable/c/fa8c776f4c323a9fbc8ddf25edcb962083391430
- https://git.kernel.org/stable/c/70e5b013538d5e4cb421afed431a5fcd2a5d49ee
- https://git.kernel.org/stable/c/cc32ba2fdf3f8b136619fff551f166ba51ec856d
- https://git.kernel.org/stable/c/d487e7ba1bc7444d5f062c4930ef8436c47c7e63
- https://git.kernel.org/stable/c/d6a9608af9a75d13243d217f6ce1e30e57d56ffe
- https://git.kernel.org/stable/c/f27d319df055629480b84b9288a502337b6f2a2e
- https://git.kernel.org/stable/c/fa8c776f4c323a9fbc8ddf25edcb962083391430
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-01-10
CVE-2024-26782
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix double-free on socket dismantle
when MPTCP server accepts an incoming connection, it clones its listener
socket. However, the pointer to 'inet_opt' for the new socket has the same
value as the original one: as a consequence, on program exit it's possible
to observe the following splat:
BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0
Free of addr ffff888485950880 by task swapper/25/0
CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609
Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013
Call Trace:
- https://git.kernel.org/stable/c/10048689def7e40a4405acda16fdc6477d4ecc5c
- https://git.kernel.org/stable/c/4a4eeb6912538c2d0b158e8d11b62d96c1dada4e
- https://git.kernel.org/stable/c/85933e80d077c9ae2227226beb86c22f464059cc
- https://git.kernel.org/stable/c/ce0809ada38dca8d6d41bb57ab40494855c30582
- https://git.kernel.org/stable/c/d93fd40c62397326046902a2c5cb75af50882a85
- https://git.kernel.org/stable/c/f74362a004225df935863dea6eb7d82daaa5b16e
- https://git.kernel.org/stable/c/10048689def7e40a4405acda16fdc6477d4ecc5c
- https://git.kernel.org/stable/c/4a4eeb6912538c2d0b158e8d11b62d96c1dada4e
- https://git.kernel.org/stable/c/85933e80d077c9ae2227226beb86c22f464059cc
- https://git.kernel.org/stable/c/ce0809ada38dca8d6d41bb57ab40494855c30582
- https://git.kernel.org/stable/c/d93fd40c62397326046902a2c5cb75af50882a85
- https://git.kernel.org/stable/c/f74362a004225df935863dea6eb7d82daaa5b16e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-04
CVE-2024-26786
In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix iopt_access_list_id overwrite bug Syzkaller reported the following WARN_ON: WARNING: CPU: 1 PID: 4738 at drivers/iommu/iommufd/io_pagetable.c:1360 Call Trace: iommufd_access_change_ioas+0x2fe/0x4e0 iommufd_access_destroy_object+0x50/0xb0 iommufd_object_remove+0x2a3/0x490 iommufd_object_destroy_user iommufd_access_destroy+0x71/0xb0 iommufd_test_staccess_release+0x89/0xd0 __fput+0x272/0xb50 __fput_sync+0x4b/0x60 __do_sys_close __se_sys_close __x64_sys_close+0x8b/0x110 do_syscall_x64 The mismatch between the access pointer in the list and the passed-in pointer is resulting from an overwrite of access->iopt_access_list_id, in iopt_add_access(). Called from iommufd_access_change_ioas() when xa_alloc() succeeds but iopt_calculate_iova_alignment() fails. Add a new_id in iopt_add_access() and only update iopt_access_list_id when returning successfully.
- https://git.kernel.org/stable/c/9526a46cc0c378d381560279bea9aa34c84298a0
- https://git.kernel.org/stable/c/aeb004c0cd6958e910123a1607634401009c9539
- https://git.kernel.org/stable/c/f1fb745ee0a6fe43f1d84ec369c7e6af2310fda9
- https://git.kernel.org/stable/c/9526a46cc0c378d381560279bea9aa34c84298a0
- https://git.kernel.org/stable/c/aeb004c0cd6958e910123a1607634401009c9539
- https://git.kernel.org/stable/c/f1fb745ee0a6fe43f1d84ec369c7e6af2310fda9
Modified: 2025-03-20
CVE-2024-26787
In the Linux kernel, the following vulnerability has been resolved: mmc: mmci: stm32: fix DMA API overlapping mappings warning Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320 DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg are not correctly balanced. If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path.
- https://git.kernel.org/stable/c/0224cbc53ba82b84affa7619b6d1b1a254bc2c53
- https://git.kernel.org/stable/c/176e66269f0de327375fc0ea51c12c2f5a97e4c4
- https://git.kernel.org/stable/c/5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c
- https://git.kernel.org/stable/c/6b1ba3f9040be5efc4396d86c9752cdc564730be
- https://git.kernel.org/stable/c/70af82bb9c897faa25a44e4181f36c60312b71ef
- https://git.kernel.org/stable/c/d610a307225951929b9dff807788439454476f85
- https://git.kernel.org/stable/c/0224cbc53ba82b84affa7619b6d1b1a254bc2c53
- https://git.kernel.org/stable/c/176e66269f0de327375fc0ea51c12c2f5a97e4c4
- https://git.kernel.org/stable/c/5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c
- https://git.kernel.org/stable/c/6b1ba3f9040be5efc4396d86c9752cdc564730be
- https://git.kernel.org/stable/c/70af82bb9c897faa25a44e4181f36c60312b71ef
- https://git.kernel.org/stable/c/d610a307225951929b9dff807788439454476f85
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-04-01
CVE-2024-26788
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: init irq after reg initialization Initialize the qDMA irqs after the registers are configured so that interrupts that may have been pending from a primary kernel don't get processed by the irq handler before it is ready to and cause panic with the following trace: Call trace: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x178 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/0xe8 fsl_qdma_probe+0x4d4/0xca8 platform_drv_probe+0x50/0xa0 really_probe+0xe0/0x3f8 driver_probe_device+0x64/0x130 device_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable+0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18
- https://git.kernel.org/stable/c/3cc5fb824c2125aa3740d905b3e5b378c8a09478
- https://git.kernel.org/stable/c/4529c084a320be78ff2c5e64297ae998c6fdf66b
- https://git.kernel.org/stable/c/474d521da890b3e3585335fb80a6044cb2553d99
- https://git.kernel.org/stable/c/677102a930643c31f1b4c512b041407058bdfef8
- https://git.kernel.org/stable/c/87a39071e0b639f45e05d296cc0538eef44ec0bd
- https://git.kernel.org/stable/c/9579a21e99fe8dab22a253050ddff28d340d74e1
- https://git.kernel.org/stable/c/a69c8bbb946936ac4eb6a6ae1e849435aa8d947d
- https://git.kernel.org/stable/c/3cc5fb824c2125aa3740d905b3e5b378c8a09478
- https://git.kernel.org/stable/c/4529c084a320be78ff2c5e64297ae998c6fdf66b
- https://git.kernel.org/stable/c/474d521da890b3e3585335fb80a6044cb2553d99
- https://git.kernel.org/stable/c/677102a930643c31f1b4c512b041407058bdfef8
- https://git.kernel.org/stable/c/87a39071e0b639f45e05d296cc0538eef44ec0bd
- https://git.kernel.org/stable/c/9579a21e99fe8dab22a253050ddff28d340d74e1
- https://git.kernel.org/stable/c/a69c8bbb946936ac4eb6a6ae1e849435aa8d947d
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-27
CVE-2024-26790
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read There is chip (ls1028a) errata: The SoC may hang on 16 byte unaligned read transactions by QDMA. Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller. Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ). Implement this workaround.
- https://git.kernel.org/stable/c/106c1ac953a66556ec77456c46e818208d3a9bce
- https://git.kernel.org/stable/c/237ecf1afe6c22534fa43abdf2bf0b0f52de0aaa
- https://git.kernel.org/stable/c/518d78b4fac68cac29a263554d7f3b19da99d0da
- https://git.kernel.org/stable/c/5b696e9c388251f1c7373be92293769a489fd367
- https://git.kernel.org/stable/c/9d739bccf261dd93ec1babf82f5c5d71dd4caa3e
- https://git.kernel.org/stable/c/ad2f8920c314e0a2d9e984fc94b729eca3cda471
- https://git.kernel.org/stable/c/bb3a06e9b9a30e33d96aadc0e077be095a4f8580
- https://git.kernel.org/stable/c/106c1ac953a66556ec77456c46e818208d3a9bce
- https://git.kernel.org/stable/c/237ecf1afe6c22534fa43abdf2bf0b0f52de0aaa
- https://git.kernel.org/stable/c/518d78b4fac68cac29a263554d7f3b19da99d0da
- https://git.kernel.org/stable/c/5b696e9c388251f1c7373be92293769a489fd367
- https://git.kernel.org/stable/c/9d739bccf261dd93ec1babf82f5c5d71dd4caa3e
- https://git.kernel.org/stable/c/ad2f8920c314e0a2d9e984fc94b729eca3cda471
- https://git.kernel.org/stable/c/bb3a06e9b9a30e33d96aadc0e077be095a4f8580
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2024-12-20
CVE-2024-26791
In the Linux kernel, the following vulnerability has been resolved: btrfs: dev-replace: properly validate device names There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel(). Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later. This was originally analyzed and fixed in a different way by Edward Adam Davis (see links).
- https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84
- https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d
- https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb
- https://git.kernel.org/stable/c/9845664b9ee47ce7ee7ea93caf47d39a9d4552c4
- https://git.kernel.org/stable/c/ab2d68655d0f04650bef09fee948ff80597c5fb9
- https://git.kernel.org/stable/c/b1690ced4d2d8b28868811fb81cd33eee5aefee1
- https://git.kernel.org/stable/c/c6652e20d7d783d060fe5f987eac7b5cabe31311
- https://git.kernel.org/stable/c/f590040ce2b712177306b03c2a63b16f7d48d3c8
- https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84
- https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d
- https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb
- https://git.kernel.org/stable/c/9845664b9ee47ce7ee7ea93caf47d39a9d4552c4
- https://git.kernel.org/stable/c/ab2d68655d0f04650bef09fee948ff80597c5fb9
- https://git.kernel.org/stable/c/b1690ced4d2d8b28868811fb81cd33eee5aefee1
- https://git.kernel.org/stable/c/c6652e20d7d783d060fe5f987eac7b5cabe31311
- https://git.kernel.org/stable/c/f590040ce2b712177306b03c2a63b16f7d48d3c8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2024-12-20
CVE-2024-26792
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix double free of anonymous device after snapshot creation failure
When creating a snapshot we may do a double free of an anonymous device
in case there's an error committing the transaction. The second free may
result in freeing an anonymous device number that was allocated by some
other subsystem in the kernel or another btrfs filesystem.
The steps that lead to this:
1) At ioctl.c:create_snapshot() we allocate an anonymous device number
and assign it to pending_snapshot->anon_dev;
2) Then we call btrfs_commit_transaction() and end up at
transaction.c:create_pending_snapshot();
3) There we call btrfs_get_new_fs_root() and pass it the anonymous device
number stored in pending_snapshot->anon_dev;
4) btrfs_get_new_fs_root() frees that anonymous device number because
btrfs_lookup_fs_root() returned a root - someone else did a lookup
of the new root already, which could some task doing backref walking;
5) After that some error happens in the transaction commit path, and at
ioctl.c:create_snapshot() we jump to the 'fail' label, and after
that we free again the same anonymous device number, which in the
meanwhile may have been reallocated somewhere else, because
pending_snapshot->anon_dev still has the same value as in step 1.
Recently syzbot ran into this and reported the following trace:
------------[ cut here ]------------
ida_free called for id=51 which is not allocated.
WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525
Modules linked in:
CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525
Code: 10 42 80 3c 28 (...)
RSP: 0018:ffffc90015a67300 EFLAGS: 00010246
RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000
RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000
RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4
R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246
R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246
FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0
Call Trace:
- https://git.kernel.org/stable/c/c34adc20b91a8e55e048b18d63f4f4ae003ecf8f
- https://git.kernel.org/stable/c/c8ab7521665bd0f8bc4a900244d1d5a7095cc3b9
- https://git.kernel.org/stable/c/e2b54eaf28df0c978626c9736b94f003b523b451
- https://git.kernel.org/stable/c/eb3441093aad251418921246fc3b224fd1575701
- https://git.kernel.org/stable/c/c34adc20b91a8e55e048b18d63f4f4ae003ecf8f
- https://git.kernel.org/stable/c/c8ab7521665bd0f8bc4a900244d1d5a7095cc3b9
- https://git.kernel.org/stable/c/e2b54eaf28df0c978626c9736b94f003b523b451
- https://git.kernel.org/stable/c/eb3441093aad251418921246fc3b224fd1575701
Modified: 2024-12-20
CVE-2024-26793
In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-deref in gtp_newlink() The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: [ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ? arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ? mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ? lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ? netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] ____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ? drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map ---truncated---
- https://git.kernel.org/stable/c/01129059d5141d62fae692f7a336ae3bc712d3eb
- https://git.kernel.org/stable/c/5366969a19a8a0d2ffb3d27ef6e8905e5e4216f8
- https://git.kernel.org/stable/c/616d82c3cfa2a2146dd7e3ae47bda7e877ee549e
- https://git.kernel.org/stable/c/9376d059a705c5dfaac566c2d09891242013ae16
- https://git.kernel.org/stable/c/93dd420bc41531c9a31498b9538ca83ba6ec191e
- https://git.kernel.org/stable/c/abd32d7f5c0294c1b2454c5a3b13b18446bac627
- https://git.kernel.org/stable/c/e668b92a3a01429923fd5ca13e99642aab47de69
- https://git.kernel.org/stable/c/ec92aa2cab6f0048f10d6aa4f025c5885cb1a1b6
- https://git.kernel.org/stable/c/01129059d5141d62fae692f7a336ae3bc712d3eb
- https://git.kernel.org/stable/c/5366969a19a8a0d2ffb3d27ef6e8905e5e4216f8
- https://git.kernel.org/stable/c/616d82c3cfa2a2146dd7e3ae47bda7e877ee549e
- https://git.kernel.org/stable/c/9376d059a705c5dfaac566c2d09891242013ae16
- https://git.kernel.org/stable/c/93dd420bc41531c9a31498b9538ca83ba6ec191e
- https://git.kernel.org/stable/c/abd32d7f5c0294c1b2454c5a3b13b18446bac627
- https://git.kernel.org/stable/c/e668b92a3a01429923fd5ca13e99642aab47de69
- https://git.kernel.org/stable/c/ec92aa2cab6f0048f10d6aa4f025c5885cb1a1b6
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-19
CVE-2024-26795
In the Linux kernel, the following vulnerability has been resolved: riscv: Sparse-Memory/vmemmap out-of-bounds fix Offset vmemmap so that the first page of vmemmap will be mapped to the first page of physical memory in order to ensure that vmemmap’s bounds will be respected during pfn_to_page()/page_to_pfn() operations. The conversion macros will produce correct SV39/48/57 addresses for every possible/valid DRAM_BASE inside the physical memory limits. v2:Address Alex's comments
- https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe
- https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef
- https://git.kernel.org/stable/c/8310080799b40fd9f2a8b808c657269678c149af
- https://git.kernel.org/stable/c/8af1c121b0102041809bc137ec600d1865eaeedd
- https://git.kernel.org/stable/c/a11dd49dcb9376776193e15641f84fcc1e5980c9
- https://git.kernel.org/stable/c/a278d5c60f21aa15d540abb2f2da6e6d795c3e6e
- https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe
- https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef
- https://git.kernel.org/stable/c/8310080799b40fd9f2a8b808c657269678c149af
- https://git.kernel.org/stable/c/8af1c121b0102041809bc137ec600d1865eaeedd
- https://git.kernel.org/stable/c/a11dd49dcb9376776193e15641f84fcc1e5980c9
- https://git.kernel.org/stable/c/a278d5c60f21aa15d540abb2f2da6e6d795c3e6e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-27
CVE-2024-26796
In the Linux kernel, the following vulnerability has been resolved: drivers: perf: ctr_get_width function for legacy is not defined With parameters CONFIG_RISCV_PMU_LEGACY=y and CONFIG_RISCV_PMU_SBI=n linux kernel crashes when you try perf record: $ perf record ls [ 46.749286] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 46.750199] Oops [#1] [ 46.750342] Modules linked in: [ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2 [ 46.750906] Hardware name: riscv-virtio,qemu (DT) [ 46.751184] epc : 0x0 [ 46.751430] ra : arch_perf_update_userpage+0x54/0x13e [ 46.751680] epc : 0000000000000000 ra : ffffffff8072ee52 sp : ff2000000022b8f0 [ 46.751958] gp : ffffffff81505988 tp : ff6000000290d400 t0 : ff2000000022b9c0 [ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930 [ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a1 : ff600000028fb000 [ 46.752673] a2 : 0000000ae2751268 a3 : 00000000004fb708 a4 : 0000000000000004 [ 46.752895] a5 : 0000000000000000 a6 : 000000000017ffe3 a7 : 00000000000000d2 [ 46.753117] s2 : ff600000028fb000 s3 : 0000000ae2751268 s4 : 0000000000000000 [ 46.753338] s5 : ffffffff8153e290 s6 : ff600000863b9000 s7 : ff60000002961078 [ 46.753562] s8 : ff60000002961048 s9 : ff60000002961058 s10: 0000000000000001 [ 46.753783] s11: 0000000000000018 t3 : ffffffffffffffff t4 : ffffffffffffffff [ 46.754005] t5 : ff6000000292270c t6 : ff2000000022bb30 [ 46.754179] status: 0000000200000100 badaddr: 0000000000000000 cause: 000000000000000c [ 46.754653] Code: Unable to access instruction at 0xffffffffffffffec. [ 46.754939] ---[ end trace 0000000000000000 ]--- [ 46.755131] note: perf-exec[107] exited with irqs disabled [ 46.755546] note: perf-exec[107] exited with preempt_count 4 This happens because in the legacy case the ctr_get_width function was not defined, but it is used in arch_perf_update_userpage. Also remove extra check in riscv_pmu_ctr_get_width_mask
- https://git.kernel.org/stable/c/682dc133f83e0194796e6ea72eb642df1c03dfbe
- https://git.kernel.org/stable/c/e0d17ee872cf8d0f51cc561329b8e1a0aa792bbb
- https://git.kernel.org/stable/c/e4f50e85de5a6b21dfdc0d7ca435eba4f62935c3
- https://git.kernel.org/stable/c/682dc133f83e0194796e6ea72eb642df1c03dfbe
- https://git.kernel.org/stable/c/e0d17ee872cf8d0f51cc561329b8e1a0aa792bbb
- https://git.kernel.org/stable/c/e4f50e85de5a6b21dfdc0d7ca435eba4f62935c3
Modified: 2026-03-17
CVE-2024-26798
In the Linux kernel, the following vulnerability has been resolved:
fbcon: always restore the old font data in fbcon_do_set_font()
Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when
vc_resize() failed) started restoring old font data upon failure (of
vc_resize()). But it performs so only for user fonts. It means that the
"system"/internal fonts are not restored at all. So in result, the very
first call to fbcon_do_set_font() performs no restore at all upon
failing vc_resize().
This can be reproduced by Syzkaller to crash the system on the next
invocation of font_get(). It's rather hard to hit the allocation failure
in vc_resize() on the first font_set(), but not impossible. Esp. if
fault injection is used to aid the execution/failure. It was
demonstrated by Sirius:
BUG: unable to handle page fault for address: fffffffffffffff8
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286
Call Trace:
- https://git.kernel.org/stable/c/00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f
- https://git.kernel.org/stable/c/20a4b5214f7bee13c897477168c77bbf79683c3d
- https://git.kernel.org/stable/c/2f91a96b892fab2f2543b4a55740c5bee36b1a6b
- https://git.kernel.org/stable/c/73a6bd68a1342f3a44cac9dffad81ad6a003e520
- https://git.kernel.org/stable/c/a2c881413dcc5d801bdc9535e51270cc88cb9cd8
- https://git.kernel.org/stable/c/ae68f57df3335679653868fafccd8c88ef84ae98
- https://git.kernel.org/stable/c/00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f
- https://git.kernel.org/stable/c/20a4b5214f7bee13c897477168c77bbf79683c3d
- https://git.kernel.org/stable/c/2f91a96b892fab2f2543b4a55740c5bee36b1a6b
- https://git.kernel.org/stable/c/73a6bd68a1342f3a44cac9dffad81ad6a003e520
- https://git.kernel.org/stable/c/a2c881413dcc5d801bdc9535e51270cc88cb9cd8
Modified: 2025-04-04
CVE-2024-26799
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix uninitialized pointer dmactl In the case where __lpass_get_dmactl_handle is called and the driver id dai_id is invalid the pointer dmactl is not being assigned a value, and dmactl contains a garbage value since it has not been initialized and so the null check may not work. Fix this to initialize dmactl to NULL. One could argue that modern compilers will set this to zero, but it is useful to keep this initialized as per the same way in functions __lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params. Cleans up clang scan build warning: sound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition evaluates to a garbage value [core.uninitialized.Branch]
- https://git.kernel.org/stable/c/1382d8b55129875b2e07c4d2a7ebc790183769ee
- https://git.kernel.org/stable/c/99adc8b4d2f38bf0d06483ec845bc48f60c3f8cf
- https://git.kernel.org/stable/c/d5a7726e6ea62d447b79ab5baeb537ea6bdb225b
- https://git.kernel.org/stable/c/1382d8b55129875b2e07c4d2a7ebc790183769ee
- https://git.kernel.org/stable/c/99adc8b4d2f38bf0d06483ec845bc48f60c3f8cf
- https://git.kernel.org/stable/c/d5a7726e6ea62d447b79ab5baeb537ea6bdb225b
Modified: 2025-12-11
CVE-2024-26800
In the Linux kernel, the following vulnerability has been resolved: tls: fix use-after-free on failed backlog decryption When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done. The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new ->async_done flag) that the memory has already been released.
- https://git.kernel.org/stable/c/13114dc5543069f7b97991e3b79937b6da05f5b0
- https://git.kernel.org/stable/c/1ac9fb84bc7ecd4bc6428118301d9d864d2a58d1
- https://git.kernel.org/stable/c/81be85353b0f5a7b660635634b655329b429eefe
- https://git.kernel.org/stable/c/f2b85a4cc763841843de693bbd7308fe9a2c4c89
- https://git.kernel.org/stable/c/13114dc5543069f7b97991e3b79937b6da05f5b0
- https://git.kernel.org/stable/c/1ac9fb84bc7ecd4bc6428118301d9d864d2a58d1
- https://git.kernel.org/stable/c/81be85353b0f5a7b660635634b655329b429eefe
- https://git.kernel.org/stable/c/f2b85a4cc763841843de693bbd7308fe9a2c4c89
Modified: 2024-12-20
CVE-2024-26801
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Avoid potential use-after-free in hci_error_reset
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
BT controller is not responding, the GPIO reset mechanism would
free the hci_dev and lead to a use-after-free in hci_error_reset.
Here's the call trace observed on a ChromeOS device with Intel AX201:
queue_work_on+0x3e/0x6c
__hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth
- https://git.kernel.org/stable/c/2449007d3f73b2842c9734f45f0aadb522daf592
- https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b
- https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1
- https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2
- https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090
- https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14
- https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6b0711d1
- https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03
- https://git.kernel.org/stable/c/2449007d3f73b2842c9734f45f0aadb522daf592
- https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b
- https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1
- https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2
- https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090
- https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14
- https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6b0711d1
- https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-03-04
CVE-2024-26802
In the Linux kernel, the following vulnerability has been resolved:
stmmac: Clear variable when destroying workqueue
Currently when suspending driver and stopping workqueue it is checked whether
workqueue is not NULL and if so, it is destroyed.
Function destroy_workqueue() does drain queue and does clear variable, but
it does not set workqueue variable to NULL. This can cause kernel/module
panic if code attempts to clear workqueue that was not initialized.
This scenario is possible when resuming suspended driver in stmmac_resume(),
because there is no handling for failed stmmac_hw_setup(),
which can fail and return if DMA engine has failed to initialize,
and workqueue is initialized after DMA engine.
Should DMA engine fail to initialize, resume will proceed normally,
but interface won't work and TX queue will eventually timeout,
causing 'Reset adapter' error.
This then does destroy workqueue during reset process.
And since workqueue is initialized after DMA engine and can be skipped,
it will cause kernel/module panic.
To secure against this possible crash, set workqueue variable to NULL when
destroying workqueue.
Log/backtrace from crash goes as follows:
[88.031977]------------[ cut here ]------------
[88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out
[88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398
- https://git.kernel.org/stable/c/17ccd9798fe0beda3db212cfa3ebe373f605cbd6
- https://git.kernel.org/stable/c/699b103e48ce32d03fc86c35b37ee8ae4288c7e3
- https://git.kernel.org/stable/c/8af411bbba1f457c33734795f024d0ef26d0963f
- https://git.kernel.org/stable/c/8e99556301172465c8fe33c7f78c39a3d4ce8462
- https://git.kernel.org/stable/c/f72cf22dccc94038cbbaa1029cb575bf52e5cbc8
- https://git.kernel.org/stable/c/17ccd9798fe0beda3db212cfa3ebe373f605cbd6
- https://git.kernel.org/stable/c/699b103e48ce32d03fc86c35b37ee8ae4288c7e3
- https://git.kernel.org/stable/c/8af411bbba1f457c33734795f024d0ef26d0963f
- https://git.kernel.org/stable/c/8e99556301172465c8fe33c7f78c39a3d4ce8462
- https://git.kernel.org/stable/c/f72cf22dccc94038cbbaa1029cb575bf52e5cbc8
Modified: 2025-04-01
CVE-2024-26803
In the Linux kernel, the following vulnerability has been resolved: net: veth: clear GRO when clearing XDP even when down veth sets NETIF_F_GRO automatically when XDP is enabled, because both features use the same NAPI machinery. The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which is called both on ndo_stop and when XDP is turned off. To avoid the flag from being cleared when the device is brought down, the clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not modify its features. Unfortunately, this means that clearing is also skipped when XDP is disabled _while_ the device is down. And there's nothing on the open path to bring the device features back into sync. IOW if user enables XDP, disables it and then brings the device up we'll end up with a stray GRO flag set but no NAPI instances. We don't depend on the GRO flag on the datapath, so the datapath won't crash. We will crash (or hang), however, next time features are sync'ed (either by user via ethtool or peer changing its config). The GRO flag will go away, and veth will try to disable the NAPIs. But the open path never created them since XDP was off, the GRO flag was a stray. If NAPI was initialized before we'll hang in napi_disable(). If it never was we'll crash trying to stop uninitialized hrtimer. Move the GRO flag updates to the XDP enable / disable paths, instead of mixing them with the ndo_open / ndo_close paths.
- https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664
- https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325
- https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941
- https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c
- https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736
- https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664
- https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325
- https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941
- https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c
- https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736
Modified: 2025-03-21
CVE-2024-26804
In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ... but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely.
- https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b
- https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee
- https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f
- https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9
- https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96
- https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282
- https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383
- https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b
- https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee
- https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f
- https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9
- https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96
- https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282
- https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-02-27
CVE-2024-26805
In the Linux kernel, the following vulnerability has been resolved: netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter syzbot reported the following uninit-value access issue [1]: netlink_to_full_skb() creates a new `skb` and puts the `skb->data` passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data size is specified as `len` and passed to skb_put_data(). This `len` is based on `skb->end` that is not data offset but buffer offset. The `skb->end` contains data and tailroom. Since the tailroom is not initialized when the new `skb` created, KMSAN detects uninitialized memory area when copying the data. This patch resolved this issue by correct the len from `skb->end` to `skb->len`, which is the actual data offset. BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages ---truncated---
- https://git.kernel.org/stable/c/0b27bf4c494d61e5663baa34c3edd7ccebf0ea44
- https://git.kernel.org/stable/c/59fc3e3d049e39e7d0d271f20dd5fb47c57faf1d
- https://git.kernel.org/stable/c/661779e1fcafe1b74b3f3fe8e980c1e207fea1fd
- https://git.kernel.org/stable/c/9ae51361da43270f4ba0eb924427a07e87e48777
- https://git.kernel.org/stable/c/c71ed29d15b1a1ed6c464f8c3536996963046285
- https://git.kernel.org/stable/c/d3ada42e534a83b618bbc1e490d23bf0fdae4736
- https://git.kernel.org/stable/c/ec343a55b687a452f5e87f3b52bf9f155864df65
- https://git.kernel.org/stable/c/f19d1f98e60e68b11fc60839105dd02a30ec0d77
- https://git.kernel.org/stable/c/0b27bf4c494d61e5663baa34c3edd7ccebf0ea44
- https://git.kernel.org/stable/c/59fc3e3d049e39e7d0d271f20dd5fb47c57faf1d
- https://git.kernel.org/stable/c/661779e1fcafe1b74b3f3fe8e980c1e207fea1fd
- https://git.kernel.org/stable/c/9ae51361da43270f4ba0eb924427a07e87e48777
- https://git.kernel.org/stable/c/c71ed29d15b1a1ed6c464f8c3536996963046285
- https://git.kernel.org/stable/c/d3ada42e534a83b618bbc1e490d23bf0fdae4736
- https://git.kernel.org/stable/c/ec343a55b687a452f5e87f3b52bf9f155864df65
- https://git.kernel.org/stable/c/f19d1f98e60e68b11fc60839105dd02a30ec0d77
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-03
CVE-2024-26807
In the Linux kernel, the following vulnerability has been resolved: Both cadence-quadspi ->runtime_suspend() and ->runtime_resume() implementations start with: struct cqspi_st *cqspi = dev_get_drvdata(dev); struct spi_controller *host = dev_get_drvdata(dev); This obviously cannot be correct, unless "struct cqspi_st" is the first member of " struct spi_controller", or the other way around, but it is not the case. "struct spi_controller" is allocated by devm_spi_alloc_host(), which allocates an extra amount of memory for private data, used to store "struct cqspi_st". The ->probe() function of the cadence-quadspi driver then sets the device drvdata to store the address of the "struct cqspi_st" structure. Therefore: struct cqspi_st *cqspi = dev_get_drvdata(dev); is correct, but: struct spi_controller *host = dev_get_drvdata(dev); is not, as it makes "host" point not to a "struct spi_controller" but to the same "struct cqspi_st" structure as above. This obviously leads to bad things (memory corruption, kernel crashes) directly during ->probe(), as ->probe() enables the device using PM runtime, leading the ->runtime_resume() hook being called, which in turns calls spi_controller_resume() with the wrong pointer. This has at least been reported [0] to cause a kernel crash, but the exact behavior will depend on the memory contents. [0] https://lore.kernel.org/all/20240226121803.5a7r5wkpbbowcxgx@dhruva/ This issue potentially affects all platforms that are currently using the cadence-quadspi driver.
- https://git.kernel.org/stable/c/03f1573c9587029730ca68503f5062105b122f61
- https://git.kernel.org/stable/c/2c914aac9522f6e93822c18dff233d3e92399c81
- https://git.kernel.org/stable/c/32ce3bb57b6b402de2aec1012511e7ac4e7449dc
- https://git.kernel.org/stable/c/34e1d5c4407c78de0e3473e1fbf8fb74dbe66d03
- https://git.kernel.org/stable/c/03f1573c9587029730ca68503f5062105b122f61
- https://git.kernel.org/stable/c/32ce3bb57b6b402de2aec1012511e7ac4e7449dc
- https://git.kernel.org/stable/c/34e1d5c4407c78de0e3473e1fbf8fb74dbe66d03
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-09-16
CVE-2024-26847
In the Linux kernel, the following vulnerability has been resolved: powerpc/rtas: use correct function name for resetting TCE tables The PAPR spec spells the function name as "ibm,reset-pe-dma-windows" but in practice firmware uses the singular form: "ibm,reset-pe-dma-window" in the device tree. Since we have the wrong spelling in the RTAS function table, reverse lookups (token -> name) fail and warn: unexpected failed lookup for token 86 WARNING: CPU: 1 PID: 545 at arch/powerpc/kernel/rtas.c:659 __do_enter_rtas_trace+0x2a4/0x2b4 CPU: 1 PID: 545 Comm: systemd-udevd Not tainted 6.8.0-rc4 #30 Hardware name: IBM,9105-22A POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NL1060_028) hv:phyp pSeries NIP [c0000000000417f0] __do_enter_rtas_trace+0x2a4/0x2b4 LR [c0000000000417ec] __do_enter_rtas_trace+0x2a0/0x2b4 Call Trace: __do_enter_rtas_trace+0x2a0/0x2b4 (unreliable) rtas_call+0x1f8/0x3e0 enable_ddw.constprop.0+0x4d0/0xc84 dma_iommu_dma_supported+0xe8/0x24c dma_set_mask+0x5c/0xd8 mlx5_pci_init.constprop.0+0xf0/0x46c [mlx5_core] probe_one+0xfc/0x32c [mlx5_core] local_pci_probe+0x68/0x12c pci_call_probe+0x68/0x1ec pci_device_probe+0xbc/0x1a8 really_probe+0x104/0x570 __driver_probe_device+0xb8/0x224 driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x120 driver_attach+0x34/0x48 bus_add_driver+0x174/0x304 driver_register+0x8c/0x1c4 __pci_register_driver+0x68/0x7c mlx5_init+0xb8/0x118 [mlx5_core] do_one_initcall+0x60/0x388 do_init_module+0x7c/0x2a4 init_module_from_file+0xb4/0x108 idempotent_init_module+0x184/0x34c sys_finit_module+0x90/0x114 And oopses are possible when lockdep is enabled or the RTAS tracepoints are active, since those paths dereference the result of the lookup. Use the correct spelling to match firmware's behavior, adjusting the related constants to match.
- https://git.kernel.org/stable/c/6b6282d56b14879124416a23837af9bd52ae2dfb
- https://git.kernel.org/stable/c/dd63817baf334888289877ab1db1d866af2a6479
- https://git.kernel.org/stable/c/fad87dbd48156ab940538f052f1820f4b6ed2819
- https://git.kernel.org/stable/c/6b6282d56b14879124416a23837af9bd52ae2dfb
- https://git.kernel.org/stable/c/dd63817baf334888289877ab1db1d866af2a6479
- https://git.kernel.org/stable/c/fad87dbd48156ab940538f052f1820f4b6ed2819
Modified: 2026-04-18
CVE-2024-26849
In the Linux kernel, the following vulnerability has been resolved: netlink: add nla be16/32 types to minlen array BUG: KMSAN: uninit-value in nla_validate_range_unsigned lib/nlattr.c:222 [inline] BUG: KMSAN: uninit-value in nla_validate_int_range lib/nlattr.c:336 [inline] BUG: KMSAN: uninit-value in validate_nla lib/nlattr.c:575 [inline] BUG: KMSAN: uninit-value in __nla_validate_parse+0x2e20/0x45c0 lib/nlattr.c:631 nla_validate_range_unsigned lib/nlattr.c:222 [inline] nla_validate_int_range lib/nlattr.c:336 [inline] validate_nla lib/nlattr.c:575 [inline] ... The message in question matches this policy: [NFTA_TARGET_REV] = NLA_POLICY_MAX(NLA_BE32, 255), but because NLA_BE32 size in minlen array is 0, the validation code will read past the malformed (too small) attribute. Note: Other attributes, e.g. BITFIELD32, SINT, UINT.. are also missing: those likely should be added too.
- https://git.kernel.org/stable/c/000a68159c0326b46c42ec712ab98793e7e625a7
- https://git.kernel.org/stable/c/0ac219c4c3ab253f3981f346903458d20bacab32
- https://git.kernel.org/stable/c/7a9d14c63b35f89563c5ecbadf918ad64979712d
- https://git.kernel.org/stable/c/80b40f9cb87f3bf5877dfb852765cf92bc03ca77
- https://git.kernel.org/stable/c/9a0d18853c280f6a0ee99f91619f2442a17a323a
- https://git.kernel.org/stable/c/a2ab028151841cd833cb53eb99427e0cc990112d
- https://git.kernel.org/stable/c/0ac219c4c3ab253f3981f346903458d20bacab32
- https://git.kernel.org/stable/c/7a9d14c63b35f89563c5ecbadf918ad64979712d
- https://git.kernel.org/stable/c/9a0d18853c280f6a0ee99f91619f2442a17a323a
- https://git.kernel.org/stable/c/a2ab028151841cd833cb53eb99427e0cc990112d
Modified: 2025-03-04
CVE-2024-26850
In the Linux kernel, the following vulnerability has been resolved: mm/debug_vm_pgtable: fix BUG_ON with pud advanced test Architectures like powerpc add debug checks to ensure we find only devmap PUD pte entries. These debug checks are only done with CONFIG_DEBUG_VM. This patch marks the ptes used for PUD advanced test devmap pte entries so that we don't hit on debug checks on architecture like ppc64 as below. WARNING: CPU: 2 PID: 1 at arch/powerpc/mm/book3s64/radix_pgtable.c:1382 radix__pud_hugepage_update+0x38/0x138 .... NIP [c0000000000a7004] radix__pud_hugepage_update+0x38/0x138 LR [c0000000000a77a8] radix__pudp_huge_get_and_clear+0x28/0x60 Call Trace: [c000000004a2f950] [c000000004a2f9a0] 0xc000000004a2f9a0 (unreliable) [c000000004a2f980] [000d34c100000000] 0xd34c100000000 [c000000004a2f9a0] [c00000000206ba98] pud_advanced_tests+0x118/0x334 [c000000004a2fa40] [c00000000206db34] debug_vm_pgtable+0xcbc/0x1c48 [c000000004a2fc10] [c00000000000fd28] do_one_initcall+0x60/0x388 Also kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:202! .... NIP [c000000000096510] pudp_huge_get_and_clear_full+0x98/0x174 LR [c00000000206bb34] pud_advanced_tests+0x1b4/0x334 Call Trace: [c000000004a2f950] [000d34c100000000] 0xd34c100000000 (unreliable) [c000000004a2f9a0] [c00000000206bb34] pud_advanced_tests+0x1b4/0x334 [c000000004a2fa40] [c00000000206db34] debug_vm_pgtable+0xcbc/0x1c48 [c000000004a2fc10] [c00000000000fd28] do_one_initcall+0x60/0x388
- https://git.kernel.org/stable/c/720da1e593b85a550593b415bf1d79a053133451
- https://git.kernel.org/stable/c/d2a9510c0e39d06f5544075c13040407bdbf2803
- https://git.kernel.org/stable/c/eeeddf85fc58d48c58ad916e4ca12363ebd8ab21
- https://git.kernel.org/stable/c/720da1e593b85a550593b415bf1d79a053133451
- https://git.kernel.org/stable/c/d2a9510c0e39d06f5544075c13040407bdbf2803
- https://git.kernel.org/stable/c/eeeddf85fc58d48c58ad916e4ca12363ebd8ab21
Modified: 2025-09-18
CVE-2024-27408
In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup The Linked list element and pointer are not stored in the same memory as the eDMA controller register. If the doorbell register is toggled before the full write of the linked list a race condition error will occur. In remote setup we can only use a readl to the memory to assure the full write has occurred.
- https://git.kernel.org/stable/c/bbcc1c83f343e580c3aa1f2a8593343bf7b55bba
- https://git.kernel.org/stable/c/d24fe6d5a1cfdddb7a9ef56736ec501c4d0a5fd3
- https://git.kernel.org/stable/c/f396b4df27cfe01a99f4b41f584c49e56477be3a
- https://git.kernel.org/stable/c/bbcc1c83f343e580c3aa1f2a8593343bf7b55bba
- https://git.kernel.org/stable/c/d24fe6d5a1cfdddb7a9ef56736ec501c4d0a5fd3
- https://git.kernel.org/stable/c/f396b4df27cfe01a99f4b41f584c49e56477be3a
Modified: 2025-09-18
CVE-2024-27409
In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: HDMA: Add sync read before starting the DMA transfer in remote setup The Linked list element and pointer are not stored in the same memory as the HDMA controller register. If the doorbell register is toggled before the full write of the linked list a race condition error will occur. In remote setup we can only use a readl to the memory to assure the full write has occurred.
- https://git.kernel.org/stable/c/17be6f5cb223f22e4733ed8fe8b2247cbb677716
- https://git.kernel.org/stable/c/227ef58a9b0c372efba422e8886a8015a1509eba
- https://git.kernel.org/stable/c/712a92a48158e02155b4b6b21e03a817f78c9b7e
- https://git.kernel.org/stable/c/17be6f5cb223f22e4733ed8fe8b2247cbb677716
- https://git.kernel.org/stable/c/227ef58a9b0c372efba422e8886a8015a1509eba
- https://git.kernel.org/stable/c/712a92a48158e02155b4b6b21e03a817f78c9b7e
Modified: 2025-12-17
CVE-2024-27410
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject iftype change with mesh ID change It's currently possible to change the mesh ID when the interface isn't yet in mesh mode, at the same time as changing it into mesh mode. This leads to an overwrite of data in the wdev->u union for the interface type it currently has, causing cfg80211_change_iface() to do wrong things when switching. We could probably allow setting an interface to mesh while setting the mesh ID at the same time by doing a different order of operations here, but realistically there's no userspace that's going to do this, so just disallow changes in iftype when setting mesh ID.
- https://git.kernel.org/stable/c/177d574be4b58f832354ab1ef5a297aa0c9aa2df
- https://git.kernel.org/stable/c/930e826962d9f01dcd2220176134427358d112f2
- https://git.kernel.org/stable/c/a2add961a5ed25cfd6a74f9ffb9e7ab6d6ded838
- https://git.kernel.org/stable/c/f78c1375339a291cba492a70eaf12ec501d28a8e
- https://git.kernel.org/stable/c/063715c33b4c37587aeca2c83cf08ead0c542995
- https://git.kernel.org/stable/c/0cfbb26ee5e7b3d6483a73883f9f6157bca22ec9
- https://git.kernel.org/stable/c/177d574be4b58f832354ab1ef5a297aa0c9aa2df
- https://git.kernel.org/stable/c/930e826962d9f01dcd2220176134427358d112f2
- https://git.kernel.org/stable/c/99eb2159680af8786104dac80528acd5acd45980
- https://git.kernel.org/stable/c/a2add961a5ed25cfd6a74f9ffb9e7ab6d6ded838
- https://git.kernel.org/stable/c/d38d31bbbb9dc0d4d71a45431eafba03d0bc150d
- https://git.kernel.org/stable/c/f78c1375339a291cba492a70eaf12ec501d28a8e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-27412
In the Linux kernel, the following vulnerability has been resolved: power: supply: bq27xxx-i2c: Do not free non existing IRQ The bq27xxx i2c-client may not have an IRQ, in which case client->irq will be 0. bq27xxx_battery_i2c_probe() already has an if (client->irq) check wrapping the request_threaded_irq(). But bq27xxx_battery_i2c_remove() unconditionally calls free_irq(client->irq) leading to: [ 190.310742] ------------[ cut here ]------------ [ 190.310843] Trying to free already-free IRQ 0 [ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310 Followed by a backtrace when unbinding the driver. Add an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring probe() to fix this.
- https://git.kernel.org/stable/c/083686474e7c97b0f8b66df37fcb64e432e8b771
- https://git.kernel.org/stable/c/2df70149e73e79783bcbc7db4fa51ecef0e2022c
- https://git.kernel.org/stable/c/7394abc8926adee6a817bab10797e0adc898af77
- https://git.kernel.org/stable/c/cefe18e9ec84f8fe3e198ccebb815cc996eb9797
- https://git.kernel.org/stable/c/d4d813c0a14d6bf52d810a55db06a2e7e3d98eaa
- https://git.kernel.org/stable/c/d7acc4a569f5f4513120c85ea2b9f04909b7490f
- https://git.kernel.org/stable/c/e601ae81910ce6a3797876e190a2d8ef6cf828bc
- https://git.kernel.org/stable/c/fbca8bae1ba79d443a58781b45e92a73a24ac8f8
- https://git.kernel.org/stable/c/083686474e7c97b0f8b66df37fcb64e432e8b771
- https://git.kernel.org/stable/c/2df70149e73e79783bcbc7db4fa51ecef0e2022c
- https://git.kernel.org/stable/c/7394abc8926adee6a817bab10797e0adc898af77
- https://git.kernel.org/stable/c/cefe18e9ec84f8fe3e198ccebb815cc996eb9797
- https://git.kernel.org/stable/c/d4d813c0a14d6bf52d810a55db06a2e7e3d98eaa
- https://git.kernel.org/stable/c/d7acc4a569f5f4513120c85ea2b9f04909b7490f
- https://git.kernel.org/stable/c/e601ae81910ce6a3797876e190a2d8ef6cf828bc
- https://git.kernel.org/stable/c/fbca8bae1ba79d443a58781b45e92a73a24ac8f8
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-27413
In the Linux kernel, the following vulnerability has been resolved: efi/capsule-loader: fix incorrect allocation size gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t: drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^ Use the correct type instead here.
- https://git.kernel.org/stable/c/00cf21ac526011a29fc708f8912da446fac19f7b
- https://git.kernel.org/stable/c/11aabd7487857b8e7d768fefb092f66dfde68492
- https://git.kernel.org/stable/c/4b73473c050a612fb4317831371073eda07c3050
- https://git.kernel.org/stable/c/537e3f49dbe88881a6f0752beaa596942d9efd64
- https://git.kernel.org/stable/c/62a5dcd9bd3097e9813de62fa6f22815e84a0172
- https://git.kernel.org/stable/c/950d4d74d311a18baed6878dbfba8180d7e5dddd
- https://git.kernel.org/stable/c/ddc547dd05a46720866c32022300f7376c40119f
- https://git.kernel.org/stable/c/fccfa646ef3628097d59f7d9c1a3e84d4b6bb45e
- https://git.kernel.org/stable/c/00cf21ac526011a29fc708f8912da446fac19f7b
- https://git.kernel.org/stable/c/11aabd7487857b8e7d768fefb092f66dfde68492
- https://git.kernel.org/stable/c/4b73473c050a612fb4317831371073eda07c3050
- https://git.kernel.org/stable/c/537e3f49dbe88881a6f0752beaa596942d9efd64
- https://git.kernel.org/stable/c/62a5dcd9bd3097e9813de62fa6f22815e84a0172
- https://git.kernel.org/stable/c/950d4d74d311a18baed6878dbfba8180d7e5dddd
- https://git.kernel.org/stable/c/ddc547dd05a46720866c32022300f7376c40119f
- https://git.kernel.org/stable/c/fccfa646ef3628097d59f7d9c1a3e84d4b6bb45e
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-17
CVE-2024-27414
In the Linux kernel, the following vulnerability has been resolved: rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back In the commit d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks IFLA_BRIDGE_MODE length"), an adjustment was made to the old loop logic in the function `rtnl_bridge_setlink` to enable the loop to also check the length of the IFLA_BRIDGE_MODE attribute. However, this adjustment removed the `break` statement and led to an error logic of the flags writing back at the end of this function. if (have_flags) memcpy(nla_data(attr), &flags, sizeof(flags)); // attr should point to IFLA_BRIDGE_FLAGS NLA !!! Before the mentioned commit, the `attr` is granted to be IFLA_BRIDGE_FLAGS. However, this is not necessarily true fow now as the updated loop will let the attr point to the last NLA, even an invalid NLA which could cause overflow writes. This patch introduces a new variable `br_flag` to save the NLA pointer that points to IFLA_BRIDGE_FLAGS and uses it to resolve the mentioned error logic.
- https://git.kernel.org/stable/c/167d8642daa6a44b51de17f8ff0f584e1e762db7
- https://git.kernel.org/stable/c/743ad091fb46e622f1b690385bb15e3cd3daf874
- https://git.kernel.org/stable/c/831bc2728fb48a8957a824cba8c264b30dca1425
- https://git.kernel.org/stable/c/882a51a10ecf24ce135d573afa0872aef02c5125
- https://git.kernel.org/stable/c/a1227b27fcccc99dc44f912b479e01a17e2d7d31
- https://git.kernel.org/stable/c/b9fbc44159dfc3e9a7073032752d9e03f5194a6f
- https://git.kernel.org/stable/c/f2261eb994aa5757c1da046b78e3229a3ece0ad9
- https://git.kernel.org/stable/c/167d8642daa6a44b51de17f8ff0f584e1e762db7
- https://git.kernel.org/stable/c/743ad091fb46e622f1b690385bb15e3cd3daf874
- https://git.kernel.org/stable/c/831bc2728fb48a8957a824cba8c264b30dca1425
- https://git.kernel.org/stable/c/882a51a10ecf24ce135d573afa0872aef02c5125
- https://git.kernel.org/stable/c/a1227b27fcccc99dc44f912b479e01a17e2d7d31
- https://git.kernel.org/stable/c/b9fbc44159dfc3e9a7073032752d9e03f5194a6f
- https://git.kernel.org/stable/c/f2261eb994aa5757c1da046b78e3229a3ece0ad9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-26
CVE-2024-27415
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: confirm multicast packets before passing them up the stack conntrack nf_confirm logic cannot handle cloned skbs referencing the same nf_conn entry, which will happen for multicast (broadcast) frames on bridges. Example: macvlan0 | br0 / \ ethX ethY ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table. 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting. -> skb->_nfct now references a unconfirmed entry 2. skb is broad/mcast packet. bridge now passes clones out on each bridge interface. 3. skb gets passed up the stack. 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices. The clone skb->_nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RX_HANDLER_PASS. 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb. The Macvlan broadcast worker and normal confirm path will race. This race will not happen if step 2 already confirmed a clone. In that case later steps perform skb_clone() with skb->_nfct already confirmed (in hash table). This works fine. But such confirmation won't happen when eb/ip/nftables rules dropped the packets before they reached the nf_confirm step in postrouting. Pablo points out that nf_conntrack_bridge doesn't allow use of stateful nat, so we can safely discard the nf_conn entry and let inet call conntrack again. This doesn't work for bridge netfilter: skb could have a nat transformation. Also bridge nf prevents re-invocation of inet prerouting via 'sabotage_in' hook. Work around this problem by explicit confirmation of the entry at LOCAL_IN time, before upper layer has a chance to clone the unconfirmed entry. The downside is that this disables NAT and conntrack helpers. Alternative fix would be to add locking to all code parts that deal with unconfirmed packets, but even if that could be done in a sane way this opens up other problems, for example: -m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5 For multicast case, only one of such conflicting mappings will be created, conntrack only handles 1:1 NAT mappings. Users should set create a setup that explicitly marks such traffic NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass them, ruleset might have accept rules for untracked traffic already, so user-visible behaviour would change.
- https://git.kernel.org/stable/c/2b1414d5e94e477edff1d2c79030f1d742625ea0
- https://git.kernel.org/stable/c/62e7151ae3eb465e0ab52a20c941ff33bb6332e9
- https://git.kernel.org/stable/c/7c3f28599652acf431a2211168de4a583f30b6d5
- https://git.kernel.org/stable/c/80cd0487f630b5382734997c3e5e3003a77db315
- https://git.kernel.org/stable/c/cb734975b0ffa688ff6cc0eed463865bf07b6c01
- https://git.kernel.org/stable/c/2b1414d5e94e477edff1d2c79030f1d742625ea0
- https://git.kernel.org/stable/c/62e7151ae3eb465e0ab52a20c941ff33bb6332e9
- https://git.kernel.org/stable/c/7c3f28599652acf431a2211168de4a583f30b6d5
- https://git.kernel.org/stable/c/80cd0487f630b5382734997c3e5e3003a77db315
- https://git.kernel.org/stable/c/cb734975b0ffa688ff6cc0eed463865bf07b6c01
Modified: 2025-12-17
CVE-2024-27416
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST If we received HCI_EV_IO_CAPA_REQUEST while HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote does support SSP since otherwise this event shouldn't be generated.
- https://git.kernel.org/stable/c/30a5e812f78e3d1cced90e1ed750bf027599205f
- https://git.kernel.org/stable/c/79820a7e1e057120c49be07cbe10643d0706b259
- https://git.kernel.org/stable/c/7e74aa53a68bf60f6019bd5d9a9a1406ec4d4865
- https://git.kernel.org/stable/c/8e2758cc25891d2b76717aaf89b40ed215de188c
- https://git.kernel.org/stable/c/afec8f772296dd8e5a2a6f83bbf99db1b9ca877f
- https://git.kernel.org/stable/c/c3df637266df29edee85e94cab5fd7041e5753ba
- https://git.kernel.org/stable/c/df193568d61234c81de7ed4d540c01975de60277
- https://git.kernel.org/stable/c/fba268ac36ab19f9763ff90d276cde0ce6cd5f31
- https://git.kernel.org/stable/c/30a5e812f78e3d1cced90e1ed750bf027599205f
- https://git.kernel.org/stable/c/79820a7e1e057120c49be07cbe10643d0706b259
- https://git.kernel.org/stable/c/7e74aa53a68bf60f6019bd5d9a9a1406ec4d4865
- https://git.kernel.org/stable/c/8e2758cc25891d2b76717aaf89b40ed215de188c
- https://git.kernel.org/stable/c/afec8f772296dd8e5a2a6f83bbf99db1b9ca877f
- https://git.kernel.org/stable/c/c3df637266df29edee85e94cab5fd7041e5753ba
- https://git.kernel.org/stable/c/df193568d61234c81de7ed4d540c01975de60277
- https://git.kernel.org/stable/c/fba268ac36ab19f9763ff90d276cde0ce6cd5f31
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-12-23
CVE-2024-27417
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix potential "struct net" leak in inet6_rtm_getaddr() It seems that if userspace provides a correct IFA_TARGET_NETNSID value but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr() returns -EINVAL with an elevated "struct net" refcount.
- https://git.kernel.org/stable/c/10bfd453da64a057bcfd1a49fb6b271c48653cdb
- https://git.kernel.org/stable/c/1b0998fdd85776775d975d0024bca227597e836a
- https://git.kernel.org/stable/c/33a1b6bfef6def2068c8703403759024ce17053e
- https://git.kernel.org/stable/c/44112bc5c74e64f28f5a9127dc34066c7a09bd0f
- https://git.kernel.org/stable/c/810fa7d5e5202fcfb22720304b755f1bdfd4c174
- https://git.kernel.org/stable/c/8a54834c03c30e549c33d5da0975f3e1454ec906
- https://git.kernel.org/stable/c/9d4ffb5b9d879a75e4f7460e8b10e756b4dfb132
- https://git.kernel.org/stable/c/10bfd453da64a057bcfd1a49fb6b271c48653cdb
- https://git.kernel.org/stable/c/1b0998fdd85776775d975d0024bca227597e836a
- https://git.kernel.org/stable/c/33a1b6bfef6def2068c8703403759024ce17053e
- https://git.kernel.org/stable/c/44112bc5c74e64f28f5a9127dc34066c7a09bd0f
- https://git.kernel.org/stable/c/810fa7d5e5202fcfb22720304b755f1bdfd4c174
- https://git.kernel.org/stable/c/8a54834c03c30e549c33d5da0975f3e1454ec906
- https://git.kernel.org/stable/c/9d4ffb5b9d879a75e4f7460e8b10e756b4dfb132
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Modified: 2025-09-26
CVE-2024-27418
In the Linux kernel, the following vulnerability has been resolved: net: mctp: take ownership of skb in mctp_local_output Currently, mctp_local_output only takes ownership of skb on success, and we may leak an skb if mctp_local_output fails in specific states; the skb ownership isn't transferred until the actual output routing occurs. Instead, make mctp_local_output free the skb on all error paths up to the route action, so it always consumes the passed skb.
- https://git.kernel.org/stable/c/3773d65ae5154ed7df404b050fd7387a36ab5ef3
- https://git.kernel.org/stable/c/a3c8fa54e904b0ddb52a08cc2d8ac239054f61fd
- https://git.kernel.org/stable/c/a639441c880ac479495e5ab37e3c29f21ae5771b
- https://git.kernel.org/stable/c/cbebc55ceacef1fc0651e80e0103cc184552fc68
- https://git.kernel.org/stable/c/3773d65ae5154ed7df404b050fd7387a36ab5ef3
- https://git.kernel.org/stable/c/a3c8fa54e904b0ddb52a08cc2d8ac239054f61fd
- https://git.kernel.org/stable/c/a639441c880ac479495e5ab37e3c29f21ae5771b
- https://git.kernel.org/stable/c/cbebc55ceacef1fc0651e80e0103cc184552fc68
Modified: 2026-01-09
CVE-2024-58240
In the Linux kernel, the following vulnerability has been resolved: tls: separate no-async decryption request handling from async If we're not doing async, the handling is much simpler. There's no reference counting, we just need to wait for the completion to wake us up and return its result. We should preferably also use a separate crypto_wait. I'm not seeing a UAF as I did in the past, I think aec7961916f3 ("tls: fix race between async notify and socket close") took care of it. This will make the next fix easier.
- https://git.kernel.org/stable/c/41532b785e9d79636b3815a64ddf6a096647d011
- https://git.kernel.org/stable/c/48905146d11dbf1ddbb2967319016a83976953f5
- https://git.kernel.org/stable/c/999115298017a675d8ddf61414fc7a85c89f1186
- https://git.kernel.org/stable/c/dec5b6e7b211e405d3bcb504562ab21aa7e5a64d
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
