ALT-PU-2025-16604-1
Package kernel-image-std-def updated to version 5.10.238-alt1 for branch p10 in task 386310.
Closed vulnerabilities
Modified: 2026-01-20
BDU:2024-10603
Уязвимость функции of_modalias() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-11
BDU:2025-04343
Уязвимость функции ice_free_cpu_rx_rmap() модуля drivers/net/ethernet/intel/ice/ice_arfs.c - драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-04-13
BDU:2025-06490
Уязвимость модуля net/sched/sch_hfsc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-07485
Уязвимость функции tcf_mirred_to_dev() модуля net/sched/act_mirred.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-08788
Уязвимость функции btrfs_prelim_ref() модуля include/trace/events/btrfs.h ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-08789
Уязвимость модуля drivers/net/vxlan/vxlan_core.c ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации
Modified: 2026-03-13
BDU:2025-08915
Уязвимость функции tipc_aead_encrypt_done() модуля net/tipc/crypto.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-08916
Уязвимость модуля drivers/media/usb/cx231xx/cx231xx-417.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-09006
Уязвимость функции queue_work() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-13
BDU:2025-09017
Уязвимость функции macb_halt_tx() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-09039
Уязвимость функции mt76_dma_cleanup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-10613
Уязвимость функции rxe_create_cq операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-10614
Уязвимость функции nfs_get_lock_context операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-10762
Уязвимость функции nvmet_tcp_set_queue_sock операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-11790
Уязвимость компонента parisc ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11829
Уязвимость компонента nouveau_fence.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в осблуживании
Modified: 2026-03-13
BDU:2025-11835
Уязвимость функции pktgen_thread_write() компонента net/core/pktgen.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-25
BDU:2025-11857
Уязвимость компонента sch_ets.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-03-13
BDU:2025-11862
Уязвимость компонента net/can/bcm.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11866
Уязвимость компонента trace.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-03-30
BDU:2025-11924
Уязвимость компонента init.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-03-13
BDU:2025-11927
Уязвимость компонента fs/orangefs/inode.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11970
Уязвимость функции output_userspace() компонента net/openvswitch/actions.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-11988
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-25
BDU:2025-11998
Уязвимость компонента sch_drr.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-03-25
BDU:2025-11999
Уязвимость компонента net/sched/sch_qfq.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-03-13
BDU:2025-12000
Уязвимость функции nd_label_data_init() компонента drivers/nvdimm/label.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12014
Уязвимость компонента drivers/dma/ti/k3-udma.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-25
BDU:2025-12033
Уязвимость компонентов microchip ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12058
Уязвимость функции hash_accept() компонента crypto/algif_hash.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-12065
Уязвимость компонента net/can/bcm.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-11
BDU:2025-12066
Уязвимость функции hfsc_enqueue() компонента net/sched/sch_hfsc.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-12086
Уязвимость компонента irq-gic-v2m.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12107
Уязвимость функции find_cifs_entry() в модуле fs/smb/client/readdir.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-13
BDU:2025-12119
Уязвимость компонента iscsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12123
Уязвимость компонента ucsi/displayport.c ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12124
Уязвимость компонентов net/sched/ ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12241
Уязвимость компонента drivers/md/dm-cache-target.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12254
Уязвимость ядра операционной системы Linux, связанная с ошибками инициализации памяти, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12256
Уязвимость компонентов xenbus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-13
BDU:2025-12277
Уязвимость функции __legitimize_mnt() компонента fs/namespace.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12333
Уязвимость ядра операционной системы Linux, связанная с доступом к неинициализированному указателю, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12334
Уязвимость ядра операционной системы Linux, связанная с доступом к неинициализированному указателю, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12349
Уязвимость компонента net/sched/sch_hfsc.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12350
Уязвимость функции st_lsm6dsx_read_fifo() компонента st_lsm6dsx_buffer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12351
Уязвимость функции st_lsm6dsx_read_tagged_fifo() компонента st_lsm6dsx_buffer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-12-26
BDU:2025-16079
Уязвимость функции write_same() драйвера SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-10
CVE-2022-21546
In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like "sg_write_same --ndob" we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer.
- https://git.kernel.org/stable/c/4226622647e3e5ac06d3ebc1605b917446157510
- https://git.kernel.org/stable/c/54e57be2573cf0b8bf650375fd8752987b6c3d3b
- https://git.kernel.org/stable/c/ccd3f449052449a917a3e577d8ba0368f43b8f29
- https://git.kernel.org/stable/c/d8e6a27e9238dd294d6f2f401655f300dca20899
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-18
CVE-2022-49063
In the Linux kernel, the following vulnerability has been resolved: ice: arfs: fix use-after-free when freeing @rx_cpu_rmap The CI testing bots triggered the following splat: [ 718.203054] BUG: KASAN: use-after-free in free_irq_cpu_rmap+0x53/0x80 [ 718.206349] Read of size 4 at addr ffff8881bd127e00 by task sh/20834 [ 718.212852] CPU: 28 PID: 20834 Comm: sh Kdump: loaded Tainted: G S W IOE 5.17.0-rc8_nextqueue-devqueue-02643-g23f3121aca93 #1 [ 718.219695] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0012.070720200218 07/07/2020 [ 718.223418] Call Trace: [ 718.227139] [ 718.230783] dump_stack_lvl+0x33/0x42 [ 718.234431] print_address_description.constprop.9+0x21/0x170 [ 718.238177] ? free_irq_cpu_rmap+0x53/0x80 [ 718.241885] ? free_irq_cpu_rmap+0x53/0x80 [ 718.245539] kasan_report.cold.18+0x7f/0x11b [ 718.249197] ? free_irq_cpu_rmap+0x53/0x80 [ 718.252852] free_irq_cpu_rmap+0x53/0x80 [ 718.256471] ice_free_cpu_rx_rmap.part.11+0x37/0x50 [ice] [ 718.260174] ice_remove_arfs+0x5f/0x70 [ice] [ 718.263810] ice_rebuild_arfs+0x3b/0x70 [ice] [ 718.267419] ice_rebuild+0x39c/0xb60 [ice] [ 718.270974] ? asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 718.274472] ? ice_init_phy_user_cfg+0x360/0x360 [ice] [ 718.278033] ? delay_tsc+0x4a/0xb0 [ 718.281513] ? preempt_count_sub+0x14/0xc0 [ 718.284984] ? delay_tsc+0x8f/0xb0 [ 718.288463] ice_do_reset+0x92/0xf0 [ice] [ 718.292014] ice_pci_err_resume+0x91/0xf0 [ice] [ 718.295561] pci_reset_function+0x53/0x80 <...> [ 718.393035] Allocated by task 690: [ 718.433497] Freed by task 20834: [ 718.495688] Last potentially related work creation: [ 718.568966] The buggy address belongs to the object at ffff8881bd127e00 which belongs to the cache kmalloc-96 of size 96 [ 718.574085] The buggy address is located 0 bytes inside of 96-byte region [ffff8881bd127e00, ffff8881bd127e60) [ 718.579265] The buggy address belongs to the page: [ 718.598905] Memory state around the buggy address: [ 718.601809] ffff8881bd127d00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.604796] ffff8881bd127d80: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc [ 718.607794] >ffff8881bd127e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.610811] ^ [ 718.613819] ffff8881bd127e80: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 718.617107] ffff8881bd127f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc This is due to that free_irq_cpu_rmap() is always being called *after* (devm_)free_irq() and thus it tries to work with IRQ descs already freed. For example, on device reset the driver frees the rmap right before allocating a new one (the splat above). Make rmap creation and freeing function symmetrical with {request,free}_irq() calls i.e. do that on ifup/ifdown instead of device probe/remove/resume. These operations can be performed independently from the actual device aRFS configuration. Also, make sure ice_vsi_free_irq() clears IRQ affinity notifiers only when aRFS is disabled -- otherwise, CPU rmap sets and clears its own and they must not be touched manually.
- https://git.kernel.org/stable/c/618df75f2e30c7838a3e010ca32cd4893ec9fe33
- https://git.kernel.org/stable/c/ba2f6ec28733fb6b24ed086e676df3df4c138f3f
- https://git.kernel.org/stable/c/d08d2fb6d99d82da1c63aba5c0d1c6f237e150f3
- https://git.kernel.org/stable/c/d7442f512b71fc63a99c8a801422dde4fbbf9f93
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-25
CVE-2024-26739
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: don't override retval if we already lost the skb If we're redirecting the skb, and haven't called tcf_mirred_forward(), yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called tcf_mirred_forward(), however, the skb is out of our hands and returning SHOT will lead to UaF. Move the retval override to the error path which actually need it.
- https://git.kernel.org/stable/c/0117fe0a4615a7c8d30d6ebcbf87332fbe63e6fd
- https://git.kernel.org/stable/c/166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210
- https://git.kernel.org/stable/c/28cdbbd38a4413b8eff53399b3f872fd4e80db9d
- https://git.kernel.org/stable/c/9d3ef89b6a5e9f2e940de2cef3d543be0be8dec5
- https://git.kernel.org/stable/c/e873e8f7d03a2ee5b77fb1a305c782fed98e2754
- https://git.kernel.org/stable/c/f4e294bbdca8ac8757db436fc82214f3882fc7e7
- https://git.kernel.org/stable/c/166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210
- https://git.kernel.org/stable/c/28cdbbd38a4413b8eff53399b3f872fd4e80db9d
- https://git.kernel.org/stable/c/f4e294bbdca8ac8757db436fc82214f3882fc7e7
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-03
CVE-2024-38541
In the Linux kernel, the following vulnerability has been resolved: of: module: add buffer overflow check in of_modalias() In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).
- https://git.kernel.org/stable/c/0b0d5701a8bf02f8fee037e81aacf6746558bfd6
- https://git.kernel.org/stable/c/46795440ef2b4ac919d09310a69a404c5bc90a88
- https://git.kernel.org/stable/c/5d59fd637a8af42b211a92b2edb2474325b4d488
- https://git.kernel.org/stable/c/733e62786bdf1b2b9dbb09ba2246313306503414
- https://git.kernel.org/stable/c/c7f24b7d94549ff4623e8f41ea4d9f5319bd8ac8
- https://git.kernel.org/stable/c/cf7385cb26ac4f0ee6c7385960525ad534323252
- https://git.kernel.org/stable/c/e45b69360a63165377b30db4a1dfddd89ca18e9a
- https://git.kernel.org/stable/c/ee332023adfd5882808f2dabf037b32d6ce36f9e
- https://git.kernel.org/stable/c/0b0d5701a8bf02f8fee037e81aacf6746558bfd6
- https://git.kernel.org/stable/c/cf7385cb26ac4f0ee6c7385960525ad534323252
- https://git.kernel.org/stable/c/e45b69360a63165377b30db4a1dfddd89ca18e9a
- https://git.kernel.org/stable/c/ee332023adfd5882808f2dabf037b32d6ce36f9e
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-12
CVE-2025-37819
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode() With ACPI in place, gicv2m_get_fwnode() is registered with the pci subsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime during a PCI host bridge probe. But, the call back is wrongly marked as __init, causing it to be freed, while being registered with the PCI subsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548 This is easily reproducible on a Juno board with ACPI boot. Retain the function for later use.
- https://git.kernel.org/stable/c/0c241dedc43a036599757cd08f356253fa3e5014
- https://git.kernel.org/stable/c/2f2803e4b5e4df2b08d378deaab78b1681ef9b30
- https://git.kernel.org/stable/c/3318dc299b072a0511d6dfd8367f3304fb6d9827
- https://git.kernel.org/stable/c/3939d6f29d34cdb60e3f68b76e39e00a964a1d51
- https://git.kernel.org/stable/c/47bee0081b483b077c7560bc5358ad101f89c8ef
- https://git.kernel.org/stable/c/b63de43af8d215b0499eac28b2caa4439183efc1
- https://git.kernel.org/stable/c/dc0d654eb4179b06d3206e4396d072108b9ba082
- https://git.kernel.org/stable/c/f95659affee301464f0d058d528d96b35b452da8
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-17
CVE-2025-37890
In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc As described in Gerrard's report [1], we have a UAF case when an hfsc class has a netem child qdisc. The crux of the issue is that hfsc is assuming that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted the class in the vttree or eltree (which is not true for the netem duplicate case). This patch checks the n_active class variable to make sure that the code won't insert the class in the vttree or eltree twice, catering for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
- https://git.kernel.org/stable/c/141d34391abbb315d68556b7c67ad97885407547
- https://git.kernel.org/stable/c/273bbcfa53541cde38b2003ad88a59b770306421
- https://git.kernel.org/stable/c/2e7093c7a8aba5d4f8809f271488e5babe75e202
- https://git.kernel.org/stable/c/6082a87af4c52f58150d40dec1716011d871ac21
- https://git.kernel.org/stable/c/8df7d37d626430035b413b97cee18396b3450bef
- https://git.kernel.org/stable/c/ac39fd4a757584d78ed062d4f6fd913f83bd98b5
- https://git.kernel.org/stable/c/e0cf8ee23e1915431f262a7b2dee0c7a7d699af0
- https://git.kernel.org/stable/c/e3e949a39a91d1f829a4890e7dfe9417ac72e4d0
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-17
CVE-2025-37909
In the Linux kernel, the following vulnerability has been resolved: net: lan743x: Fix memleak issue when GSO enabled Always map the `skb` to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak
- https://git.kernel.org/stable/c/093855ce90177488eac772de4eefbb909033ce5f
- https://git.kernel.org/stable/c/189b05f189cac9fd233ef04d31cb5078c4d09c39
- https://git.kernel.org/stable/c/2d52e2e38b85c8b7bc00dca55c2499f46f8c8198
- https://git.kernel.org/stable/c/6c65ee5ad632eb8dcd3a91cf5dc99b22535f44d9
- https://git.kernel.org/stable/c/a0e0efbabbbe6a1859bc31bf65237ce91e124b9b
- https://git.kernel.org/stable/c/dae1ce27ceaea7e1522025b15252e3cc52802622
- https://git.kernel.org/stable/c/df993daa4c968b4b23078eacc248f6502ede8664
- https://git.kernel.org/stable/c/f42c18e2f14c1b1fdd2a5250069a84bc854c398c
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-17
CVE-2025-37913
In the Linux kernel, the following vulnerability has been resolved: net_sched: qfq: Fix double list add in class with netem as child qdisc As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of qfq, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. This patch checks whether the class was already added to the agg->active list (cl_is_active) before doing the addition to cater for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
- https://git.kernel.org/stable/c/005a479540478a820c52de098e5e767e63e36f0a
- https://git.kernel.org/stable/c/041f410aec2c1751ee22b8b73ba05d38c3a6a602
- https://git.kernel.org/stable/c/0aa23e0856b7cedb3c88d8e3d281c212c7e4fbeb
- https://git.kernel.org/stable/c/0bf32d6fb1fcbf841bb9945570e0e2a70072c00f
- https://git.kernel.org/stable/c/370218e8ce711684acc4cdd3cc3c6dd7956bc165
- https://git.kernel.org/stable/c/53bc0b55178bd59bdd4bcd16349505cabf54b1a2
- https://git.kernel.org/stable/c/a43783119e01849fbf2fe8855634e8989b240cb4
- https://git.kernel.org/stable/c/f139f37dcdf34b67f5bf92bc8e0f7f6b3ac63aa4
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-17
CVE-2025-37914
In the Linux kernel, the following vulnerability has been resolved: net_sched: ets: Fix double list add in class with netem as child qdisc As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of ets, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before doing the addition to cater for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
- https://git.kernel.org/stable/c/1a6d0c00fa07972384b0c308c72db091d49988b6
- https://git.kernel.org/stable/c/1f01e9f961605eb397c6ecd1d7b0233dfbf9077c
- https://git.kernel.org/stable/c/24388ba0a1b1b6d4af1b205927ac7f7b119ee4ea
- https://git.kernel.org/stable/c/554acc5a2ea9703e08023eb9a003f9e5a830a502
- https://git.kernel.org/stable/c/72c3da7e6ceb74e74ddbb5a305a35c9fdfcac6e3
- https://git.kernel.org/stable/c/9efb6a0fa88e0910d079fdfeb4f7ce4d4ac6c990
- https://git.kernel.org/stable/c/bc321f714de693aae06e3786f88df2975376d996
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-17
CVE-2025-37915
In the Linux kernel, the following vulnerability has been resolved: net_sched: drr: Fix double list add in class with netem as child qdisc As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of drr, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before adding to the list to cover for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
- https://git.kernel.org/stable/c/26e75716b94d6ff9be5ea07d63675c4d189f30b4
- https://git.kernel.org/stable/c/2968632880f1792007eedd12eeedf7f6e2b7e9f3
- https://git.kernel.org/stable/c/4b07ac06b0a712923255aaf2691637693fc7100d
- https://git.kernel.org/stable/c/4f0ecf50cdf76da95828578a92f130b653ac2fcf
- https://git.kernel.org/stable/c/5da3aad1a13e7edb8ff0778a444ccf49930313e9
- https://git.kernel.org/stable/c/ab2248110738d4429668140ad22f530a9ee730e1
- https://git.kernel.org/stable/c/db205b92dfe0501e5b92fb7cf00971d0e44ba3eb
- https://git.kernel.org/stable/c/f99a3fbf023e20b626be4b0f042463d598050c9a
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-10
CVE-2025-37923
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix oob write in trace_seq_to_buffer()
syzbot reported this bug:
==================================================================
BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]
BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822
Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260
CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
Call Trace:
- https://git.kernel.org/stable/c/056ebbddb8faf4ddf83d005454dd78fc25c2d897
- https://git.kernel.org/stable/c/1a3f9482b50b74fa9421bff8ceecfefd0dc06f8f
- https://git.kernel.org/stable/c/1f27a3e93b8d674b24b27fcdbc6f72743cd96c0d
- https://git.kernel.org/stable/c/441021e5b3c7d9bd1b963590652c415929f3b157
- https://git.kernel.org/stable/c/665ce421041890571852422487f4c613d1824ba9
- https://git.kernel.org/stable/c/c5d2b66c5ef5037b4b4360e5447605ff00ba1bd4
- https://git.kernel.org/stable/c/f4b0174e9f18aaba59ee6ffdaf8827a7f94eb606
- https://git.kernel.org/stable/c/f5178c41bb43444a6008150fe6094497135d07cb
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-10
CVE-2025-37927
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256. The same applies to the hid string with length 13 and uid string with length 250. Check the length of hid and uid strings separately to prevent buffer overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/10d901a95f8e766e5aa0bb9a983fb41271f64718
- https://git.kernel.org/stable/c/13d67528e1ae4486e9ab24b70122fab104c73c29
- https://git.kernel.org/stable/c/2b65060c84ee4d8dc64fae6d2728b528e9e832e1
- https://git.kernel.org/stable/c/466d9da267079a8d3b69fa72dfa3a732e1f6dbb5
- https://git.kernel.org/stable/c/8dee308e4c01dea48fc104d37f92d5b58c50b96c
- https://git.kernel.org/stable/c/a65ebfed65fa62797ec1f5f1dcf7adb157a2de1e
- https://git.kernel.org/stable/c/c3f37faa71f5d26dd2144b3f2b14525ec8f5e41f
- https://git.kernel.org/stable/c/c8bdfc0297965bb13fa439d36ca9c4f7c8447f0f
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-10
CVE-2025-37930
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill() Nouveau is mostly designed in a way that it's expected that fences only ever get signaled through nouveau_fence_signal(). However, in at least one other place, nouveau_fence_done(), can signal fences, too. If that happens (race) a signaled fence remains in the pending list for a while, until it gets removed by nouveau_fence_update(). Should nouveau_fence_context_kill() run in the meantime, this would be a bug because the function would attempt to set an error code on an already signaled fence. Have nouveau_fence_context_kill() check for a fence being signaled.
- https://git.kernel.org/stable/c/0453825167ecc816ec15c736e52316f69db0deb9
- https://git.kernel.org/stable/c/126f5c6e0cb84e5c6f7a3a856d799d85668fb38e
- https://git.kernel.org/stable/c/2ec0f5f6d4768f292c8406ed92fa699f184577e5
- https://git.kernel.org/stable/c/39d6e889c0b19a2c79e1c74c843ea7c2d0f99c28
- https://git.kernel.org/stable/c/47ca11836c35c5698088fd87f7fb4b0ffa217e17
- https://git.kernel.org/stable/c/b771b2017260ffc3a8d4e81266619649bffcb242
- https://git.kernel.org/stable/c/bbe5679f30d7690a9b6838a583b9690ea73fe0e9
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-37949
In the Linux kernel, the following vulnerability has been resolved:
xenbus: Use kref to track req lifetime
Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
- https://git.kernel.org/stable/c/0e94a246bb6d9538010b6c02d2b1d4717a97b2e5
- https://git.kernel.org/stable/c/1f0304dfd9d217c2f8b04a9ef4b3258a66eedd27
- https://git.kernel.org/stable/c/2466b0f66795c3c426cacc8998499f38031dbb59
- https://git.kernel.org/stable/c/4d260a5558df4650eb87bc41b2c9ac2d6b2ba447
- https://git.kernel.org/stable/c/8b02f85e84dc6f7c150cef40ddb69af5a25659e5
- https://git.kernel.org/stable/c/8e9c8a0393b5f85f1820c565ab8105660f4e8f92
- https://git.kernel.org/stable/c/cbfaf46b88a4c01b64c4186cdccd766c19ae644c
- https://git.kernel.org/stable/c/f1bcac367bc95631afbb918348f30dec887d0e1b
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37969
In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.
- https://git.kernel.org/stable/c/16857370b3a30663515956b3bd27f3def6a2cf06
- https://git.kernel.org/stable/c/35b8c0a284983b71d92d082c54b7eb655ed4194f
- https://git.kernel.org/stable/c/4db7d923a8c298788181b796f71adf6ca499f966
- https://git.kernel.org/stable/c/76727a1d81afde77d21ea8feaeb12d34605be6f4
- https://git.kernel.org/stable/c/8114ef86e2058e2554111b793596f17bee23fa15
- https://git.kernel.org/stable/c/9ce662851380fe2018e36e15c0bdcb1ad177ed95
- https://git.kernel.org/stable/c/9ddb4cf2192c213e4dba1733bbcdc94cf6d85bf7
- https://git.kernel.org/stable/c/dadf9116108315f2eb14c7415c7805f392c476b4
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37970
In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.
- https://git.kernel.org/stable/c/159ca7f18129834b6f4c7eae67de48e96c752fc9
- https://git.kernel.org/stable/c/3bb6c02d6fe8347ce1785016d135ff539c20043c
- https://git.kernel.org/stable/c/6c4a5000618a8c44200d455c92e2f2a4db264717
- https://git.kernel.org/stable/c/84e39f628a3a3333add99076e4d6c8b42b12d3a0
- https://git.kernel.org/stable/c/a1cad8a3bca41dead9980615d35efc7bff1fd534
- https://git.kernel.org/stable/c/da33c4167b9cc1266a97215114cb74679f881d0c
- https://git.kernel.org/stable/c/f06a1a1954527cc4ed086d926c81ff236b2adde9
- https://git.kernel.org/stable/c/f3cf233c946531a92fe651ff2bd15ebbe60630a7
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37990
In the Linux kernel, the following vulnerability has been resolved: wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage() The function brcmf_usb_dl_writeimage() calls the function brcmf_usb_dl_cmd() but dose not check its return value. The 'state.state' and the 'state.bytes' are uninitialized if the function brcmf_usb_dl_cmd() fails. It is dangerous to use uninitialized variables in the conditions. Add error handling for brcmf_usb_dl_cmd() to jump to error handling path if the brcmf_usb_dl_cmd() fails and the 'state.state' and the 'state.bytes' are uninitialized. Improve the error message to report more detailed error information.
- https://git.kernel.org/stable/c/08424a0922fb9e32a19b09d852ee87fb6c497538
- https://git.kernel.org/stable/c/508be7c001437bacad7b9a43f08a723887bcd1ea
- https://git.kernel.org/stable/c/524b70441baba453b193c418e3142bd31059cc1f
- https://git.kernel.org/stable/c/62a4f2955d9a1745bdb410bf83fb16666d8865d6
- https://git.kernel.org/stable/c/8e089e7b585d95122c8122d732d1d5ef8f879396
- https://git.kernel.org/stable/c/972bf75e53f778c78039c5d139dd47443a6d66a1
- https://git.kernel.org/stable/c/bdb435ef9815b1ae28eefffa01c6959d0fcf1fa7
- https://git.kernel.org/stable/c/fa9b9f02212574ee1867fbefb0a675362a71b31d
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37991
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix double SIGFPE crash Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately. When the T bit is set, an assist exception trap occurs when when the co-processor encounters *any* floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace. The issue can be reproduced with this test program: root@parisc:~# cat fpe.c static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); } int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); } root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 vars */) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception
- https://git.kernel.org/stable/c/2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6
- https://git.kernel.org/stable/c/6a098c51d18ec99485668da44294565c43dbc106
- https://git.kernel.org/stable/c/6c639af49e9e5615a8395981eaf5943fb40acd6f
- https://git.kernel.org/stable/c/757ba4d17b868482837c566cfefca59e2296c608
- https://git.kernel.org/stable/c/cf21e890f56b7d0038ddaf25224e4f4c69ecd143
- https://git.kernel.org/stable/c/de3629baf5a33af1919dec7136d643b0662e85ef
- https://git.kernel.org/stable/c/df3592e493d7f29bae4ffde9a9325de50ddf962e
- https://git.kernel.org/stable/c/ec4584495868bd465fe60a3f771915c0e7ce7951
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-37992
In the Linux kernel, the following vulnerability has been resolved: net_sched: Flush gso_skb list too during ->change() Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen. This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.
- https://git.kernel.org/stable/c/2d3cbfd6d54a2c39ce3244f33f85c595844bd7b8
- https://git.kernel.org/stable/c/a7d6e0ac0a8861f6b1027488062251a8e28150fd
- https://git.kernel.org/stable/c/d1365ca80b012d8a7863e45949e413fb61fa4861
- https://git.kernel.org/stable/c/d3336f746f196c6a53e0480923ae93939f047b6c
- https://git.kernel.org/stable/c/d38939ebe0d992d581acb6885c1723fa83c1fb2c
- https://git.kernel.org/stable/c/ea1132ccb112f51ba749c56a912f67970c2cd542
- https://git.kernel.org/stable/c/fe88c7e4fc2c1cd75a278a15ffbf1689efad4e76
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37994
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix NULL pointer access This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal.
- https://git.kernel.org/stable/c/076ab0631ed4928905736f1701e25f1e722bc086
- https://git.kernel.org/stable/c/14f298c52188c34acde9760bf5abc669c5c36fdb
- https://git.kernel.org/stable/c/312d79669e71283d05c05cc49a1a31e59e3d9e0e
- https://git.kernel.org/stable/c/5ad298d6d4aebe1229adba6427e417e89a5208d8
- https://git.kernel.org/stable/c/7804c4d63edfdd5105926cc291e806e8f4ce01b5
- https://git.kernel.org/stable/c/9dda1e2a666a8a32ce0f153b5dee05c7351f1020
- https://git.kernel.org/stable/c/a9931f1b52b2d0bf3952e003fd5901ea7eb851ed
- https://git.kernel.org/stable/c/e9b63faf5c97deb43fc39a52edbc39d626cc14bf
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37995
In the Linux kernel, the following vulnerability has been resolved: module: ensure that kobject_put() is safe for module type kobjects In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe.
- https://git.kernel.org/stable/c/31d8df3f303c3ae9115230820977ef8c35c88808
- https://git.kernel.org/stable/c/93799fb988757cdacf19acba57807746c00378e6
- https://git.kernel.org/stable/c/9e7b49ce4f9d0cb5b6e87db9e07a2fb9e754b0dd
- https://git.kernel.org/stable/c/a63d99873547d8b39eb2f6db79dd235761e7098a
- https://git.kernel.org/stable/c/a6aeb739974ec73e5217c75a7c008a688d3d5cf1
- https://git.kernel.org/stable/c/d63851049f412cdfadaeef7a7eaef5031d11c1e9
- https://git.kernel.org/stable/c/f1c71b4bd721a4ea21da408806964b10468623f2
- https://git.kernel.org/stable/c/faa9059631d3491d699c69ecf512de9e1a3d6649
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37997
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix region locking in hash types Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahash_bucket_start(), ahash_bucket_end() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts.
- https://git.kernel.org/stable/c/00cfc5fad1491796942a948808afb968a0a3f35b
- https://git.kernel.org/stable/c/226ce0ec38316d9e3739e73a64b6b8304646c658
- https://git.kernel.org/stable/c/6e002ecc1c8cfdfc866b9104ab7888da54613e59
- https://git.kernel.org/stable/c/82c1eb32693bc48251d92532975e19160987e5b9
- https://git.kernel.org/stable/c/8478a729c0462273188263136880480729e9efca
- https://git.kernel.org/stable/c/a3dfec485401943e315c394c29afe2db8f9481d6
- https://git.kernel.org/stable/c/aa77294b0f73bb8265987591460cd25b8722c3df
- https://git.kernel.org/stable/c/e2ab67672b2288521a6146034a971f9a82ffc5c5
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37998
In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix unsafe attribute parsing in output_userspace() This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed.
- https://git.kernel.org/stable/c/0236742bd959332181c1fcc41a05b7b709180501
- https://git.kernel.org/stable/c/06b4f110c79716c181a8c5da007c259807840232
- https://git.kernel.org/stable/c/47f7f00cf2fa3137d5c0416ef1a71bdf77901395
- https://git.kernel.org/stable/c/4fa672cbce9c86c3efb8621df1ae580d47813430
- https://git.kernel.org/stable/c/6712dc21506738f5f22b4f68b7c0d9e0df819dbd
- https://git.kernel.org/stable/c/6beb6835c1fbb3f676aebb51a5fee6b77fed9308
- https://git.kernel.org/stable/c/bca8df998cce1fead8cbc69144862eadc2e34c87
- https://git.kernel.org/stable/c/ec334aaab74705cc515205e1da3cb369fdfd93cd
- https://www.zerodayinitiative.com/advisories/ZDI-25-307/
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-38000
In the Linux kernel, the following vulnerability has been resolved: sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue() When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the child qdisc's peek() operation before incrementing sch->q.qlen and sch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may trigger an immediate dequeue and potential packet drop. In such cases, qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to inconsistent queue accounting. This can leave an empty HFSC class in the active list, causing further consequences like use-after-free. This patch fixes the bug by moving the increment of sch->q.qlen and sch->qstats.backlog before the call to the child qdisc's peek() operation. This ensures that queue length and backlog are always accurate when packet drops or dequeues are triggered during the peek.
- https://git.kernel.org/stable/c/1034e3310752e8675e313f7271b348914008719a
- https://git.kernel.org/stable/c/3f3a22eebbc32b4fa8ce9c1d5f9db214b45b9335
- https://git.kernel.org/stable/c/3f981138109f63232a5fb7165938d4c945cc1b9d
- https://git.kernel.org/stable/c/49b21795b8e5654a7df3d910a12e1060da4c04cf
- https://git.kernel.org/stable/c/89c301e929a0db14ebd94b4d97764ce1d6981653
- https://git.kernel.org/stable/c/93c276942e75de0e5bc91576300d292e968f5a02
- https://git.kernel.org/stable/c/f1dde3eb17dc1b8bd07aed00004b1e05fc87a3d4
- https://git.kernel.org/stable/c/f9f593e34d2fb67644372c8f7b033bdc622ad228
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-03-07
CVE-2025-38001
In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Address reentrant enqueue adding class to eltree twice Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM. The patch only checks the cl->cl_nactive field to determine whether it is the first insertion or not [2], but this field is only incremented by init_vf [3]. By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the check and insert the class twice in the eltree. Under normal conditions, this would lead to an infinite loop in hfsc_dequeue for the reasons we already explained in this report [5]. However, if TBF is added as root qdisc and it is configured with a very low rate, it can be utilized to prevent packets from being dequeued. This behavior can be exploited to perform subsequent insertions in the HFSC eltree and cause a UAF." To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfsc_enqueue whether the class is already in the eltree whenever the HFSC_RSC flag is set. [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u
- https://git.kernel.org/stable/c/295f7c579b07b5b7cf2dffe485f71cc2f27647cb
- https://git.kernel.org/stable/c/2c928b3a0b04a431ffcd6c8b7d88a267124a3a28
- https://git.kernel.org/stable/c/2f2190ce4ca972051cac6a8d7937448f8cb9673c
- https://git.kernel.org/stable/c/39ed887b1dd2d6b720f87e86692ac3006cc111c8
- https://git.kernel.org/stable/c/4e38eaaabfb7fffbb371a51150203e19eee5d70e
- https://git.kernel.org/stable/c/6672e6c00810056acaac019fe26cdc26fee8a66c
- https://git.kernel.org/stable/c/a0ec22fa20b252edbe070a9de8501eef63c17ef5
- https://git.kernel.org/stable/c/ac9fe7dd8e730a103ae4481147395cc73492d786
- https://git.kernel.org/stable/c/e5bee633cc276410337d54b99f77fbc1ad8801e5
- https://syst3mfailure.io/rbtree-family-drama/
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
- https://syst3mfailure.io/rbtree-family-drama/
Modified: 2025-12-17
CVE-2025-38003
In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing rcu read protection for procfs content When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF). As the removal of bcm_op's is already implemented with rcu handling this patch adds the missing rcu_read_lock() and makes sure the list entries are properly removed under rcu protection.
- https://git.kernel.org/stable/c/0622846db728a5332b917c797c733e202c4620ae
- https://git.kernel.org/stable/c/19f553a1ddf260da6570ed8f8d91a8c87f49b63a
- https://git.kernel.org/stable/c/1f912f8484e9c4396378c39460bbea0af681f319
- https://git.kernel.org/stable/c/63567ecd99a24495208dc860d50fb17440043006
- https://git.kernel.org/stable/c/659701c0b954ccdb4a916a4ad59bbc16e726d42c
- https://git.kernel.org/stable/c/6d7d458c41b98a5c1670cbd36f2923c37de51cf5
- https://git.kernel.org/stable/c/7c9db92d5f0eadca30884af75c53d601edc512ee
- https://git.kernel.org/stable/c/dac5e6249159ac255dad9781793dbe5908ac9ddb
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38004
In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero. Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh. At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too.
- https://git.kernel.org/stable/c/2a437b86ac5a9893c902f30ef66815bf13587bf6
- https://git.kernel.org/stable/c/7595de7bc56e0e52b74e56c90f7e247bf626d628
- https://git.kernel.org/stable/c/76c84c3728178b2d38d5604e399dfe8b0752645e
- https://git.kernel.org/stable/c/8f1c022541bf5a923c8d6fa483112c15250f30a4
- https://git.kernel.org/stable/c/c2aba69d0c36a496ab4f2e81e9c2b271f2693fd7
- https://git.kernel.org/stable/c/c4e8a172501e677ebd8ea9d9161d97dc4df56fbd
- https://git.kernel.org/stable/c/cc55dd28c20a6611e30596019b3b2f636819a4c0
- https://git.kernel.org/stable/c/fbd8fdc2b218e979cfe422b139b8f74c12419d1f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38005
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma: Add missing locking
Recent kernels complain about a missing lock in k3-udma.c when the lock
validator is enabled:
[ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238
[ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28
[ 4.144867] Hardware name: pp-v12 (DT)
[ 4.148648] Workqueue: events udma_check_tx_completion
[ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 4.160834] pc : udma_start.isra.0+0x34/0x238
[ 4.165227] lr : udma_start.isra.0+0x30/0x238
[ 4.169618] sp : ffffffc083cabcf0
[ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005
[ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000
[ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670
[ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030
[ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048
[ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001
[ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68
[ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8
[ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000
[ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000
[ 4.244986] Call trace:
[ 4.247463] udma_start.isra.0+0x34/0x238
[ 4.251509] udma_check_tx_completion+0xd0/0xdc
[ 4.256076] process_one_work+0x244/0x3fc
[ 4.260129] process_scheduled_works+0x6c/0x74
[ 4.264610] worker_thread+0x150/0x1dc
[ 4.268398] kthread+0xd8/0xe8
[ 4.271492] ret_from_fork+0x10/0x20
[ 4.275107] irq event stamp: 220
[ 4.278363] hardirqs last enabled at (219): [
- https://git.kernel.org/stable/c/0ea0433f822ed0549715f7044c9cd1cf132ff7fa
- https://git.kernel.org/stable/c/26e63b2fe30c61bd25981c6084f67a8af79945d0
- https://git.kernel.org/stable/c/27e71fa08711e09d81e06a54007b362a5426fd22
- https://git.kernel.org/stable/c/99df1edf17493cb49a8c01f6bde55c3abb6a2a6c
- https://git.kernel.org/stable/c/d87f1cddc592387359fde157cc4296556f6403c2
- https://git.kernel.org/stable/c/df5987e76a4ae4cbd705d81ab4b15ed232250a4a
- https://git.kernel.org/stable/c/fca280992af8c2fbd511bc43f65abb4a17363f2f
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-38009
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: disable napi on driver removal
A warning on driver removal started occurring after commit 9dd05df8403b
("net: warn if NAPI instance wasn't shut down"). Disable tx napi before
deleting it in mt76_dma_cleanup().
WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100
CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy)
Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024
RIP: 0010:__netif_napi_del_locked+0xf0/0x100
Call Trace:
- https://git.kernel.org/stable/c/2b81e76db3667d1f7f2ad44e9835cdaf8dea95a8
- https://git.kernel.org/stable/c/5e700b06b970fc19e3a1ecb244e14785f3fbb8e3
- https://git.kernel.org/stable/c/78ab4be549533432d97ea8989d2f00b508fa68d8
- https://git.kernel.org/stable/c/b892e830d1ea8c5475254b98827771f7366f1039
- https://git.kernel.org/stable/c/ca5b213bf4b4224335a8131a26805d16503fca5f
- https://git.kernel.org/stable/c/e7bfbda5fddd27f3158e723d641c0fcdfb0552a7
- https://git.kernel.org/stable/c/ff0f820fa5b99035b3c654dd531226d8d83aec5f
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-38023
In the Linux kernel, the following vulnerability has been resolved:
nfs: handle failure of nfs_get_lock_context in unlock path
When memory is insufficient, the allocation of nfs_lock_context in
nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat
an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)
as valid and proceed to execute rpc_run_task(), this will trigger a NULL
pointer dereference in nfs4_locku_prepare. For example:
BUG: kernel NULL pointer dereference, address: 000000000000000c
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP PTI
CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40
Workqueue: rpciod rpc_async_schedule
RIP: 0010:nfs4_locku_prepare+0x35/0xc2
Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3
RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246
RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40
RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38
R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030
R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30
FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0
Call Trace:
- https://git.kernel.org/stable/c/4c189fd40a09a03f9a900bedb2d9064f1734d72a
- https://git.kernel.org/stable/c/72f552e00c50f265896d3c19edc6696aa2910081
- https://git.kernel.org/stable/c/85fb7f8ca5f8c138579fdfc9b97b3083e6077d40
- https://git.kernel.org/stable/c/a6879a076b98c99c9fe747816fe1c29543442441
- https://git.kernel.org/stable/c/c457dc1ec770a22636b473ce5d35614adfe97636
- https://git.kernel.org/stable/c/da824f1271633bcb515ca8084cda3eda4b3ace51
- https://git.kernel.org/stable/c/db6f5ee1fc8f54d079d0751292c2fc2d78e3aad1
- https://git.kernel.org/stable/c/f601960af04d2ecb007c928ba153d34051acd9c1
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-38024
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug
Call Trace:
- https://git.kernel.org/stable/c/16c45ced0b3839d3eee72a86bb172bef6cf58980
- https://git.kernel.org/stable/c/336edd6b0f5b7fbffc3e065285610624f59e88df
- https://git.kernel.org/stable/c/3a3b73e135e3bd18423d0baa72571319c7feb759
- https://git.kernel.org/stable/c/52daccfc3fa68ee1902d52124921453d7a335591
- https://git.kernel.org/stable/c/7c7c80c32e00665234e373ab03fe82f5c5c2c230
- https://git.kernel.org/stable/c/ee4c5a2a38596d548566560c0c022ab797e6f71a
- https://git.kernel.org/stable/c/f81b33582f9339d2dc17c69b92040d3650bb4bae
- https://git.kernel.org/stable/c/f8f470e3a757425a8f98fb9a5991e3cf62fc7134
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-18
CVE-2025-38031
In the Linux kernel, the following vulnerability has been resolved: padata: do not leak refcount in reorder_work A recent patch that addressed a UAF introduced a reference count leak: the parallel_data refcount is incremented unconditionally, regardless of the return value of queue_work(). If the work item is already queued, the incremented refcount is never decremented. Fix this by checking the return value of queue_work() and decrementing the refcount when necessary. Resolves: Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgr_probe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30
- https://git.kernel.org/stable/c/1a426abdf1c86882c9203dd8182f3b8274b89938
- https://git.kernel.org/stable/c/1c65ae4988714716101555fe2b9830e33136d6fb
- https://git.kernel.org/stable/c/5300e487487d7a2e3e1e6e9d8f03ed9452e4019e
- https://git.kernel.org/stable/c/584a729615fa92f4de45480efb7e569d14be1516
- https://git.kernel.org/stable/c/b9ad8e50e8589607e68e6c4cefa7f72bf35a2cb1
- https://git.kernel.org/stable/c/cceb15864e1612ebfbc10ec4e4dcd19a10c0056c
- https://git.kernel.org/stable/c/d6ebcde6d4ecf34f8495fb30516645db3aea8993
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38034
In the Linux kernel, the following vulnerability has been resolved:
btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref
btrfs_prelim_ref() calls the old and new reference variables in the
incorrect order. This causes a NULL pointer dereference because oldref
is passed as NULL to trace_btrfs_prelim_ref_insert().
Note, trace_btrfs_prelim_ref_insert() is being called with newref as
oldref (and oldref as NULL) on purpose in order to print out
the values of newref.
To reproduce:
echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable
Perform some writeback operations.
Backtrace:
BUG: kernel NULL pointer dereference, address: 0000000000000018
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130
Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88
RSP: 0018:ffffce44820077a0 EFLAGS: 00010286
RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b
RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010
R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000
R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540
FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/0528bba48dce7820d2da72e1a114e1c4552367eb
- https://git.kernel.org/stable/c/137bfa08c6441f324d00692d1e9d22cfd773329b
- https://git.kernel.org/stable/c/5755b6731655e248c4f1d52a2e1b18795b4a2a3a
- https://git.kernel.org/stable/c/7a97f961a568a8f72472dc804af02a0f73152c5f
- https://git.kernel.org/stable/c/7f7c8c03feba5f2454792fab3bb8bd45bd6883f9
- https://git.kernel.org/stable/c/a641154cedf9d69730f8af5d0a901fe86e6486bd
- https://git.kernel.org/stable/c/a876703894a6dd6e8c04b0635d86e9f7a7c81b79
- https://git.kernel.org/stable/c/bc7e0975093567f51be8e1bdf4aa5900a3cf0b1e
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38035
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: don't restore null sk_state_change
queue->state_change is set as part of nvmet_tcp_set_queue_sock(), but if
the TCP connection isn't established when nvmet_tcp_set_queue_sock() is
called then queue->state_change isn't set and sock->sk->sk_state_change
isn't replaced.
As such we don't need to restore sock->sk->sk_state_change if
queue->state_change is NULL.
This avoids NULL pointer dereferences such as this:
[ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode
[ 286.463796][ C0] #PF: error_code(0x0010) - not-present page
[ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0
[ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI
[ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)
[ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
[ 286.467147][ C0] RIP: 0010:0x0
[ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246
[ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43
[ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100
[ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c
[ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3
[ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268
[ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000
[ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0
[ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400
[ 286.475453][ C0] Call Trace:
[ 286.476102][ C0]
- https://git.kernel.org/stable/c/17e58be5b49f58bf17799a504f55c2d05ab2ecdc
- https://git.kernel.org/stable/c/3a982ada411b8c52695f1784c3f4784771f30209
- https://git.kernel.org/stable/c/46d22b47df2741996af277a2838b95f130436c13
- https://git.kernel.org/stable/c/6265538446e2426f4bf3b57e91d7680b2047ddd9
- https://git.kernel.org/stable/c/a21cb31642ffc84ca4ce55028212a96f72f54d30
- https://git.kernel.org/stable/c/c240375587ddcc80e1022f52ee32b946bbc3a639
- https://git.kernel.org/stable/c/ec462449f4cf616b0aa2ed119f5f44b5fdfcefab
- https://git.kernel.org/stable/c/fc01b547c3f8bfa6e1d23cd5a2c63c736e8c3e4e
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38037
In the Linux kernel, the following vulnerability has been resolved: vxlan: Annotate FDB data races The 'used' and 'updated' fields in the FDB entry structure can be accessed concurrently by multiple threads, leading to reports such as [1]. Can be reproduced using [2]. Suppress these reports by annotating these accesses using READ_ONCE() / WRITE_ONCE(). [1] BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000fffbac6e -> 0x00000000fffbac6f Reported by Kernel Concurrency Sanitizer on: CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [2] #!/bin/bash set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &
- https://git.kernel.org/stable/c/02a33b1035a307453a1da6ce0a1bf3676be287d7
- https://git.kernel.org/stable/c/13cba3f837903f7184d6e9b6137d5165ffe82a8f
- https://git.kernel.org/stable/c/4eceb7eae6ea7c950384c34e6dbbe872c981935f
- https://git.kernel.org/stable/c/784b78295a3a58bf052339dd669e6e03710220d3
- https://git.kernel.org/stable/c/87d076987a9ba106c83412fcd113656f71af05a1
- https://git.kernel.org/stable/c/a6644aeb8ddf196dec5f8e782293c36f065df4d7
- https://git.kernel.org/stable/c/e033da39fc6abbddab6c29624acef80757f273fa
- https://git.kernel.org/stable/c/f6205f8215f12a96518ac9469ff76294ae7bd612
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38044
In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: set device_caps for 417 The video_device for the MPEG encoder did not set device_caps. Add this, otherwise the video device can't be registered (you get a WARN_ON instead). Not seen before since currently 417 support is disabled, but I found this while experimenting with it.
- https://git.kernel.org/stable/c/0884dd3abbe80307a2d4cbdbe5e312be164f8adb
- https://git.kernel.org/stable/c/2ad41beb7df3bd63b209842d16765ec59dafe6e4
- https://git.kernel.org/stable/c/4731d5328f507ae8fd8a57abbca9119ec7a8d665
- https://git.kernel.org/stable/c/5c9eca180a4235abd56cc7f7308ca72128d93dce
- https://git.kernel.org/stable/c/9d1a5be86dbe074bd8dd6bdd63a99d6bb66d5930
- https://git.kernel.org/stable/c/a79efc44b51432490538a55b9753a721f7d3ea42
- https://git.kernel.org/stable/c/c91447e35b9bea60bda4408c48e7891d14351021
- https://git.kernel.org/stable/c/e43fd82bb2110bf9d13d800cdc49cceddfd0ede5
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2026-01-12
CVE-2025-38051
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix use-after-free in cifs_fill_dirent
There is a race condition in the readdir concurrency process, which may
access the rsp buffer after it has been released, triggering the
following KASAN warning.
==================================================================
BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]
Read of size 4 at addr ffff8880099b819c by task a.out/342975
CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/1b197931fbc821bc7e9e91bf619400db563e3338
- https://git.kernel.org/stable/c/73cadde98f67f76c5eba00ac0b72c453383cec8b
- https://git.kernel.org/stable/c/9bea368648ac46f8593a780760362e40291d22a9
- https://git.kernel.org/stable/c/9c9aafbacc183598f064902365e107b5e856531f
- https://git.kernel.org/stable/c/a24c2f05ac3c5b0aaa539d9d913826d2643dfd0e
- https://git.kernel.org/stable/c/a7a8fe56e932a36f43e031b398aef92341bf5ea0
- https://git.kernel.org/stable/c/aee067e88d61eb72e966f094e4749c6b14e7008f
- https://git.kernel.org/stable/c/c8623231e0edfcccb7cc6add0288fa0f0594282f
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38052
In the Linux kernel, the following vulnerability has been resolved: net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done Syzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue. I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1 The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work) Fix this by holding net reference count before encrypt.
- https://git.kernel.org/stable/c/4a0fddc2c0d5c28aec8c262ad4603be0bef1938c
- https://git.kernel.org/stable/c/689a205cd968a1572ab561b0c4c2d50a10e9d3b0
- https://git.kernel.org/stable/c/b19fc1d0be3c3397e5968fe2627f22e7f84673b1
- https://git.kernel.org/stable/c/b8fcae6d2e93c54cacb8f579a77d827c1c643eb5
- https://git.kernel.org/stable/c/d42ed4de6aba232d946d20653a70f79158a6535b
- https://git.kernel.org/stable/c/e279024617134c94fd3e37470156534d5f2b3472
- https://git.kernel.org/stable/c/f5c2c4eaaa5a8e7e0685ec031d480e588e263e59
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38058
In the Linux kernel, the following vulnerability has been resolved: __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock ... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput(). Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with.
- https://git.kernel.org/stable/c/250cf3693060a5f803c5f1ddc082bb06b16112a9
- https://git.kernel.org/stable/c/628fb00195ce21a90cf9e4e3d105cd9e58f77b40
- https://git.kernel.org/stable/c/8cafd7266fa02e0863bacbf872fe635c0b9725eb
- https://git.kernel.org/stable/c/9b0915e72b3cf52474dcee0b24a2f99d93e604a3
- https://git.kernel.org/stable/c/b55996939c71a3e1a38f3cdc6a8859797efc9083
- https://git.kernel.org/stable/c/b89eb56a378b7b2c1176787fc228d0a57172bdd5
- https://git.kernel.org/stable/c/d8ece4ced3b051e656c77180df2e69e19e24edc1
- https://git.kernel.org/stable/c/f6d45fd92f62845cbd1eb5128fd8f0ed7d0c5a42
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-18
CVE-2025-38061
In the Linux kernel, the following vulnerability has been resolved: net: pktgen: fix access outside of user given buffer in pktgen_thread_write() Honour the user given buffer size for the strn_len() calls (otherwise strn_len() will access memory outside of the user given buffer).
- https://git.kernel.org/stable/c/128cdb617a87767c29be43e4431129942fce41df
- https://git.kernel.org/stable/c/425e64440ad0a2f03bdaf04be0ae53dededbaa77
- https://git.kernel.org/stable/c/5bfa81539e22af4c40ae5d43d7212253462383a6
- https://git.kernel.org/stable/c/6b1d3e9db82d01a88de1795b879df67c2116b4f4
- https://git.kernel.org/stable/c/8fef258b555c75a467a6b4b7e3a3cbc46d5f4102
- https://git.kernel.org/stable/c/a3d89f1cfe1e6d4bb164db2595511fd33db21900
- https://git.kernel.org/stable/c/c81c2ee1c3b050ed5c4e92876590cc7a259183f6
- https://git.kernel.org/stable/c/ef1158a6a650ecee72ab40851b1d52e04d3f9cb5
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38065
In the Linux kernel, the following vulnerability has been resolved: orangefs: Do not truncate file size 'len' is used to store the result of i_size_read(), so making 'len' a size_t results in truncation to 4GiB on 32-bit systems.
- https://git.kernel.org/stable/c/062e8093592fb866b8e016641a8b27feb6ac509d
- https://git.kernel.org/stable/c/121f0335d91e46369bf55b5da4167d82b099a166
- https://git.kernel.org/stable/c/15602508ad2f923e228b9521960b4addcd27d9c4
- https://git.kernel.org/stable/c/2323b806221e6268a4e17711bc72e2fc87c191a3
- https://git.kernel.org/stable/c/341e3a5984cf5761f3dab16029d7e9fb1641d5ff
- https://git.kernel.org/stable/c/5111227d7f1f57f6804666b3abf780a23f44fc1d
- https://git.kernel.org/stable/c/cd918ec24168fe08c6aafc077dd3b6d88364c5cf
- https://git.kernel.org/stable/c/ceaf195ed285b77791e29016ee6344b3ded609b3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38066
In the Linux kernel, the following vulnerability has been resolved:
dm cache: prevent BUG_ON by blocking retries on failed device resumes
A cache device failing to resume due to mapping errors should not be
retried, as the failure leaves a partially initialized policy object.
Repeating the resume operation risks triggering BUG_ON when reloading
cache mappings into the incomplete policy object.
Reproduce steps:
1. create a cache metadata consisting of 512 or more cache blocks,
with some mappings stored in the first array block of the mapping
array. Here we use cache_restore v1.0 to build the metadata.
cat <
- https://git.kernel.org/stable/c/00586b78eeb7c626a14ca13453a1631f88a7cf36
- https://git.kernel.org/stable/c/025c8f477625eb39006ded650e7d027bcfb20e79
- https://git.kernel.org/stable/c/3986ef4a9b6a0d9c28bc325d8713beba5e67586f
- https://git.kernel.org/stable/c/5da692e2262b8f81993baa9592f57d12c2703dea
- https://git.kernel.org/stable/c/c5356a5e80442131e2714d0d26bb110590e4e568
- https://git.kernel.org/stable/c/c614584c2a66b538f469089ac089457a34590c14
- https://git.kernel.org/stable/c/cc80a5cc520939d0a7d071cc4ae4b3c55ef171d0
- https://git.kernel.org/stable/c/f3128e3074e8af565cc6a66fe3384a56df87f803
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38072
In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Fix divide error in nd_label_data_init() If a faulty CXL memory device returns a broken zero LSA size in its memory device information (Identify Memory Device (Opcode 4000h), CXL spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm driver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm] Code and flow: 1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (CXL pmem driver): drivers/cxl/pmem.c: .config_size = mds->lsa_size, 3) max_xfer is set to zero (nvdimm driver): drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size); 4) A subsequent DIV_ROUND_UP() causes a division by zero: drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */ drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, drivers/nvdimm/label.c- config_size); Fix this by checking the config size parameter by extending an existing check.
- https://git.kernel.org/stable/c/1d1e1efad1cf049e888bf175a5c6be85d792620c
- https://git.kernel.org/stable/c/2bd4a938d2eda96ab7288b8fa5aae84a1de8c4ca
- https://git.kernel.org/stable/c/396c46d3f59a18ebcc500640e749f16e197d472b
- https://git.kernel.org/stable/c/db1aef51b8e66a77f76b1250b914589c31a0a0ed
- https://git.kernel.org/stable/c/e14347f647ca6d76fe1509b6703e340f2d5e2716
- https://git.kernel.org/stable/c/ea3d95e05e97ea20fd6513f647393add16fce3b2
- https://git.kernel.org/stable/c/ef1d3455bbc1922f94a91ed58d3d7db440652959
- https://git.kernel.org/stable/c/f49c337037df029440a8390380dd35d2cf5924d3
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38075
In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix timeout on deleted connection NOPIN response timer may expire on a deleted connection and crash with such logs: Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d BUG: Kernel NULL pointer dereference on read at 0x00000000 NIP strlcpy+0x8/0xb0 LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod] Call Trace: iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod] call_timer_fn+0x58/0x1f0 run_timer_softirq+0x740/0x860 __do_softirq+0x16c/0x420 irq_exit+0x188/0x1c0 timer_interrupt+0x184/0x410 That is because nopin response timer may be re-started on nopin timer expiration. Stop nopin timer before stopping the nopin response timer to be sure that no one of them will be re-started.
- https://git.kernel.org/stable/c/019ca2804f3fb49a7f8e56ea6aeaa1ff32724c27
- https://git.kernel.org/stable/c/2c5081439c7ab8da08427befe427f0d732ebc9f9
- https://git.kernel.org/stable/c/3e6429e3707943078240a2c0c0b3ee99ea9b0d9c
- https://git.kernel.org/stable/c/571ce6b6f5cbaf7d24af03cad592fc0e2a54de35
- https://git.kernel.org/stable/c/6815846e0c3a62116a7da9740e3a7c10edc5c7e9
- https://git.kernel.org/stable/c/7f533cc5ee4c4436cee51dc58e81dfd9c3384418
- https://git.kernel.org/stable/c/87389bff743c55b6b85282de91109391f43e0814
- https://git.kernel.org/stable/c/fe8421e853ef289e1324fcda004751c89dd9c18a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38078
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race of buffer access at PCM OSS layer The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation.
- https://git.kernel.org/stable/c/10217da9644ae75cea7330f902c35fc5ba78bbbf
- https://git.kernel.org/stable/c/74d90875f3d43f3eff0e9861c4701418795d3455
- https://git.kernel.org/stable/c/8170d8ec4efd0be352c14cb61f374e30fb0c2a25
- https://git.kernel.org/stable/c/93a81ca0657758b607c3f4ba889ae806be9beb73
- https://git.kernel.org/stable/c/afa56c960fcb4db37f2e3399f28e9402e4e1f470
- https://git.kernel.org/stable/c/bf85e49aaf3a3c5775ea87369ea5f159c2148db4
- https://git.kernel.org/stable/c/c0e05a76fc727929524ef24a19c302e6dd40233f
- https://git.kernel.org/stable/c/f3e14d706ec18faf19f5a6e75060e140fea05d4a
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-17
CVE-2025-38079
In the Linux kernel, the following vulnerability has been resolved: crypto: algif_hash - fix double free in hash_accept If accept(2) is called on socket type algif_hash with MSG_MORE flag set and crypto_ahash_import fails, sk2 is freed. However, it is also freed in af_alg_release, leading to slab-use-after-free error.
- https://git.kernel.org/stable/c/0346f4b742345d1c733c977f3a7aef5a6419a967
- https://git.kernel.org/stable/c/134daaba93193df9e988524b5cd2f52d15eb1993
- https://git.kernel.org/stable/c/2f45a8d64fb4ed4830a4b3273834ecd6ca504896
- https://git.kernel.org/stable/c/5bff312b59b3f2a54ff504e4f4e47272b64f3633
- https://git.kernel.org/stable/c/b2df03ed4052e97126267e8c13ad4204ea6ba9b6
- https://git.kernel.org/stable/c/bf7bba75b91539e93615f560893a599c1e1c98bf
- https://git.kernel.org/stable/c/c3059d58f79fdfb2201249c2741514e34562b547
- https://git.kernel.org/stable/c/f0f3d09f53534ea385d55ced408f2b67059b16e4
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-38094
In the Linux kernel, the following vulnerability has been resolved: net: cadence: macb: Fix a possible deadlock in macb_halt_tx. There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock. That deadlock was noticed on a sama5d4 device that stayed locked for days. Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore.
- https://git.kernel.org/stable/c/0772a608d799ac0d127c0a36047a2725777aba9d
- https://git.kernel.org/stable/c/1d60c0781c1bbeaa1196b0d8aad5c435f06cb7c4
- https://git.kernel.org/stable/c/3e64d35475aa21d13dab71da51de51923c1a3a48
- https://git.kernel.org/stable/c/64675a9c00443b2e8af42af08c38fc1b78b68ba2
- https://git.kernel.org/stable/c/84f98955a9de0e0f591df85aa1a44f3ebcf1cb37
- https://git.kernel.org/stable/c/aace6b63892ce8307e502a60fe2f5a4bc6e1cfe7
- https://git.kernel.org/stable/c/c92d6089d8ad7d4d815ebcedee3f3907b539ff1f
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
