ALT-PU-2026-3813-6
Package kernel-image-rt updated to version 6.12.64-alt1 for branch sisyphus in task 404580.
Closed vulnerabilities
Modified: 2026-01-27
BDU:2025-16159
Уязвимость функции usbnet_resume_rx() модуля drivers/net/usb/usbnet.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2026-01568
Уязвимость функции adv7842_cp_log_status() модуля drivers/media/i2c/adv7842.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2026-01569
Уязвимость функции exynos_clkout_probe() модуля drivers/clk/samsung/clk-exynos-clkout.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2026-01598
Уязвимость функции f2fs_put_super() модуля fs/f2fs/super.c файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2026-01628
Уязвимость функции irdma_net_event() модуля drivers/infiniband/hw/irdma/utils.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02863
Уязвимость функции advance_periodic_target_expiration() модуля arch/x86/kvm/lapic.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03070
Уязвимость функции rose_kill_by_device() модуля net/rose/af_rose.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03136
Уязвимость функции ucsi_init() модуля drivers/usb/typec/ucsi/ucsi.c драйвера интерфейса разъема USB Type C (UCSI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03137
Уязвимость функции wdt_probe() модуля drivers/watchdog/via_wdt.c поддержки сторожевого таймера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03138
Уязвимость функции parse_apply_sb_mount_options() модуля fs/ext4/super.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03139
Уязвимость функции acpi_ns_walk_namespace() модуля drivers/acpi/acpica/nswalk.c драйвера ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03175
Уязвимость функции seqiv_aead_encrypt() модуля crypto/seqiv.c криптографической подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03176
Уязвимость функции raid5_store_group_thread_cnt() модуля drivers/md/raid5.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03344
Уязвимость функции dpu_encoder_phys_wb_setup_ctl() модуля drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-20
BDU:2026-03358
Уязвимость функции decode_pool() модуля net/ceph/osdmap.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2026-04-03
BDU:2026-03362
Уязвимость функции hclge_set_vlan_filter() модуля drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c драйвера сетевых адаптеров Ethernet Hisilicon ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03363
Уязвимость функции __mptcp_retrans() модуля net/mptcp/protocol.c реализации протокола MPTCP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-04-03
BDU:2026-03364
Уязвимость функции otx2_set_ringparam() модуля drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c драйвера сетевых адаптеров Ethernet Marvell ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-04-03
BDU:2026-03365
Уязвимость функции gss_read_proxy_verf() модуля net/sunrpc/auth_gss/svcauth_gss.c ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, вызвать отказ в обслуживании
Modified: 2026-04-03
BDU:2026-03368
Уязвимость функции scs_check_usage() модуля kernel/scs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-03
BDU:2026-03369
Уязвимость функции gsc_set_affinity_irq() модуля drivers/parisc/gsc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-27
BDU:2026-04911
Уязвимость функции ib_del_sub_device_and_put() модуля drivers/infiniband/core/device.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-04-27
BDU:2026-05109
Уязвимость функции sys_perf_event_open() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-26
CVE-2025-40164
In the Linux kernel, the following vulnerability has been resolved:
usbnet: Fix using smp_processor_id() in preemptible code warnings
Syzbot reported the following warning:
BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879
caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331
CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary)
Call Trace:
- https://git.kernel.org/stable/c/0134c7bff14bd50314a4f92b182850ddfc38e255
- https://git.kernel.org/stable/c/17fbad93879e87a334062882b45fa727ba1b3dd7
- https://git.kernel.org/stable/c/327cd4b68b4398b6c24f10eb2b2533ffbfc10185
- https://git.kernel.org/stable/c/65d04291adf7c59338f87aab9c6fe0bfa9993e64
- https://git.kernel.org/stable/c/d1944bab8e0c1511f0cbf364aa06547735bb0ddb
- https://git.kernel.org/stable/c/f45fffae5e2549bd0a4670cc52a15ad54c9f121e
Modified: 2026-02-26
CVE-2025-68817
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes *_put()/write on it.
- https://git.kernel.org/stable/c/063cbbc6f595ea36ad146e1b7d2af820894beb21
- https://git.kernel.org/stable/c/21a3d01fc6db5129f81edb0ab7cb94fd758bcbea
- https://git.kernel.org/stable/c/446beed646b2e426dd53d27358365f8678e1dd01
- https://git.kernel.org/stable/c/b39a1833cc4a2755b02603eec3a71a85e9dff926
- https://git.kernel.org/stable/c/d092de8a26c952379ded8e6b0bda31d89befac1a
- https://git.kernel.org/stable/c/d64977495e44855f2b28d8ce56107c963a7a50e4
Modified: 2026-04-03
CVE-2025-71068
In the Linux kernel, the following vulnerability has been resolved: svcrdma: bound check rq_pages index in inline path svc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] without verifying rc_curpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.
- https://git.kernel.org/stable/c/5f140b525180c628db8fa6c897f138194a2de417
- https://git.kernel.org/stable/c/7ba826aae1d43212f3baa53a2175ad949e21926e
- https://git.kernel.org/stable/c/a22316f5e9a29e4b92030bd8fb9435fe0eb1d5c9
- https://git.kernel.org/stable/c/d1bea0ce35b6095544ee82bb54156fc62c067e58
- https://git.kernel.org/stable/c/da1ccfc4c452541584a4eae89e337cfa21be6d5a
Modified: 2026-03-25
CVE-2025-71071
In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: fix use-after-free on probe deferral The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors. This can potentially lead to a use-after-free in case a larb device has not yet been bound to its driver so that the iommu driver probe defers. Fix this by keeping the references as expected while the iommu driver is bound.
- https://git.kernel.org/stable/c/1ef70a0b104ae8011811f60bcfaa55ff49385171
- https://git.kernel.org/stable/c/5c04217d06a1161aaf36267e9d971ab6f847d5a7
- https://git.kernel.org/stable/c/896ec55da3b90bdb9fc04fedc17ad8c359b2eee5
- https://git.kernel.org/stable/c/de83d4617f9fe059623e97acf7e1e10d209625b5
- https://git.kernel.org/stable/c/f6c08d3aa441bbc1956e9d65f1cbb89113a5aa8a
Modified: 2026-03-25
CVE-2025-71072
In the Linux kernel, the following vulnerability has been resolved: shmem: fix recovery on rename failures maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange(). Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout(). Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton. For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations. For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations. That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout().
Modified: 2026-03-25
CVE-2025-71073
In the Linux kernel, the following vulnerability has been resolved: Input: lkkbd - disable pending work before freeing device lkkbd_interrupt() schedules lk->tq via schedule_work(), and the work handler lkkbd_reinit() dereferences the lkkbd structure and its serio/input_dev fields. lkkbd_disconnect() and error paths in lkkbd_connect() free the lkkbd structure without preventing the reinit work from being queued again until serio_close() returns. This can allow the work handler to run after the structure has been freed, leading to a potential use-after-free. Use disable_work_sync() instead of cancel_work_sync() to ensure the reinit work cannot be re-queued, and call it both in lkkbd_disconnect() and in lkkbd_connect() error paths after serio_open().
Modified: 2026-03-25
CVE-2025-71075
In the Linux kernel, the following vulnerability has been resolved: scsi: aic94xx: fix use-after-free in device removal path The asd_pci_remove() function fails to synchronize with pending tasklets before freeing the asd_ha structure, leading to a potential use-after-free vulnerability. When a device removal is triggered (via hot-unplug or module unload), race condition can occur. The fix adds tasklet_kill() before freeing the asd_ha structure, ensuring all scheduled tasklets complete before cleanup proceeds.
- https://git.kernel.org/stable/c/278455a82245a572aeb218a6212a416a98e418de
- https://git.kernel.org/stable/c/751c19635c2bfaaf2836a533caa3663633066dcf
- https://git.kernel.org/stable/c/a41dc180b6e1229ae49ca290ae14d82101c148c3
- https://git.kernel.org/stable/c/b3e655e52b98a1d3df41c8e42035711e083099f8
- https://git.kernel.org/stable/c/c8f6f88cd1df35155258285c4f43268b361819df
- https://git.kernel.org/stable/c/e354793a7ab9bb0934ea699a9d57bcd1b48fc27b
- https://git.kernel.org/stable/c/f6ab594672d4cba08540919a4e6be2e202b60007
Modified: 2026-03-25
CVE-2025-71076
In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Limit num_syncs to prevent oversized allocations The OA open parameters did not validate num_syncs, allowing userspace to pass arbitrarily large values, potentially leading to excessive allocations. Add check to ensure that num_syncs does not exceed DRM_XE_MAX_SYNCS, returning -EINVAL when the limit is violated. v2: use XE_IOCTL_DBG() and drop duplicated check. (Ashutosh) (cherry picked from commit e057b2d2b8d815df3858a87dffafa2af37e5945b)
Modified: 2026-03-25
CVE-2025-71077
In the Linux kernel, the following vulnerability has been resolved: tpm: Cap the number of PCR banks tpm2_get_pcr_allocation() does not cap any upper limit for the number of banks. Cap the limit to eight banks so that out of bounds values coming from external I/O cause on only limited harm.
- https://git.kernel.org/stable/c/275c686f1e3cc056ec66c764489ec1fe1e51b950
- https://git.kernel.org/stable/c/858344bc9210bea9ab2bdc7e9e331ba84c164e50
- https://git.kernel.org/stable/c/8ceee7288152bc121a6bf92997261838c78bfe06
- https://git.kernel.org/stable/c/b69492161c056d36789aee42a87a33c18c8ed5e1
- https://git.kernel.org/stable/c/ceb70d31da5671d298bad94ae6c20e4bbb800f96
- https://git.kernel.org/stable/c/d88481653d74d622d1d0d2c9bad845fc2cc6fd23
- https://git.kernel.org/stable/c/faf07e611dfa464b201223a7253e9dc5ee0f3c9e
Modified: 2026-03-25
CVE-2025-71078
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s/slb: Fix SLB multihit issue during SLB preload On systems using the hash MMU, there is a software SLB preload cache that mirrors the entries loaded into the hardware SLB buffer. This preload cache is subject to periodic eviction — typically after every 256 context switches — to remove old entry. To optimize performance, the kernel skips switch_mmu_context() in switch_mm_irqs_off() when the prev and next mm_struct are the same. However, on hash MMU systems, this can lead to inconsistencies between the hardware SLB and the software preload cache. If an SLB entry for a process is evicted from the software cache on one CPU, and the same process later runs on another CPU without executing switch_mmu_context(), the hardware SLB may retain stale entries. If the kernel then attempts to reload that entry, it can trigger an SLB multi-hit error. The following timeline shows how stale SLB entries are created and can cause a multi-hit error when a process moves between CPUs without a MMU context switch. CPU 0 CPU 1 ----- ----- Process P exec swapper/1 load_elf_binary begin_new_exc activate_mm switch_mm_irqs_off switch_mmu_context switch_slb /* * This invalidates all * the entries in the HW * and setup the new HW * SLB entries as per the * preload cache. */ context_switch sched_migrate_task migrates process P to cpu-1 Process swapper/0 context switch (to process P) (uses mm_struct of Process P) switch_mm_irqs_off() switch_slb load_slb++ /* * load_slb becomes 0 here * and we evict an entry from * the preload cache with * preload_age(). We still * keep HW SLB and preload * cache in sync, that is * because all HW SLB entries * anyways gets evicted in * switch_slb during SLBIA. * We then only add those * entries back in HW SLB, * which are currently * present in preload_cache * (after eviction). */ load_elf_binary continues... setup_new_exec() slb_setup_new_exec() sched_switch event sched_migrate_task migrates process P to cpu-0 context_switch from swapper/0 to Process P switch_mm_irqs_off() /* * Since both prev and next mm struct are same we don't call * switch_mmu_context(). This will cause the HW SLB and SW preload * cache to go out of sync in preload_new_slb_context. Because there * was an SLB entry which was evicted from both HW and preload cache * on cpu-1. Now later in preload_new_slb_context(), when we will try * to add the same preload entry again, we will add this to the SW * preload cache and then will add it to the HW SLB. Since on cpu-0 * this entry was never invalidated, hence adding this entry to the HW * SLB will cause a SLB multi-hit error. */ load_elf_binary cont ---truncated---
- https://git.kernel.org/stable/c/00312419f0863964625d6dcda8183f96849412c6
- https://git.kernel.org/stable/c/01324c0328181b94cf390bda22ff91c75126ea57
- https://git.kernel.org/stable/c/2e9a95d60f1df7b57618fd5ef057aef331575bd2
- https://git.kernel.org/stable/c/4ae1e46d8a290319f33f71a2710a1382ba5431e8
- https://git.kernel.org/stable/c/895123c309a34d2cfccf7812b41e17261a3a6f37
- https://git.kernel.org/stable/c/b13a3dbfa196af68eae2031f209743735ad416bf
- https://git.kernel.org/stable/c/c9f865022a1823d814032a09906e91e4701a35fc
Modified: 2026-03-25
CVE-2025-71079
In the Linux kernel, the following vulnerability has been resolved: net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write A deadlock can occur between nfc_unregister_device() and rfkill_fop_write() due to lock ordering inversion between device_lock and rfkill_global_mutex. The problematic lock order is: Thread A (rfkill_fop_write): rfkill_fop_write() mutex_lock(&rfkill_global_mutex) rfkill_set_block() nfc_rfkill_set_block() nfc_dev_down() device_lock(&dev->dev) <- waits for device_lock Thread B (nfc_unregister_device): nfc_unregister_device() device_lock(&dev->dev) rfkill_unregister() mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutex This creates a classic ABBA deadlock scenario. Fix this by moving rfkill_unregister() and rfkill_destroy() outside the device_lock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkill_unregister() after releasing device_lock. This change is safe because rfkill_fop_write() holds rfkill_global_mutex while calling the rfkill callbacks, and rfkill_unregister() also acquires rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will wait for any ongoing callback to complete before proceeding, and device_del() is only called after rfkill_unregister() returns, preventing any use-after-free. The similar lock ordering in nfc_register_device() (device_lock -> rfkill_global_mutex via rfkill_register) is safe because during registration the device is not yet in rfkill_list, so no concurrent rfkill operations can occur on this device.
- https://git.kernel.org/stable/c/1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5
- https://git.kernel.org/stable/c/2e0831e9fc46a06daa6d4d8d57a2738e343130c3
- https://git.kernel.org/stable/c/6b93c8ab6f6cda8818983a4ae3fcf84b023037b4
- https://git.kernel.org/stable/c/8fc4632fb508432895430cd02b38086bdd649083
- https://git.kernel.org/stable/c/e02a1c33f10a0ed3aba855ab8ae2b6c4c5be8012
- https://git.kernel.org/stable/c/ee41f4f3ccf8cd6ba3732e867abbec7e6d8d12e5
- https://git.kernel.org/stable/c/f3a8a7c1aa278f2378b2f3a10500c6674dffdfda
Modified: 2026-03-25
CVE-2025-71080
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix a BUG in rt6_get_pcpu_route() under PREEMPT_RT On PREEMPT_RT kernels, after rt6_get_pcpu_route() returns NULL, the current task can be preempted. Another task running on the same CPU may then execute rt6_make_pcpu_route() and successfully install a pcpu_rt entry. When the first task resumes execution, its cmpxchg() in rt6_make_pcpu_route() will fail because rt6i_pcpu is no longer NULL, triggering the BUG_ON(prev). It's easy to reproduce it by adding mdelay() after rt6_get_pcpu_route(). Using preempt_disable/enable is not appropriate here because ip6_rt_pcpu_alloc() may sleep. Fix this by handling the cmpxchg() failure gracefully on PREEMPT_RT: free our allocation and return the existing pcpu_rt installed by another task. The BUG_ON is replaced by WARN_ON_ONCE for non-PREEMPT_RT kernels where such races should not occur.
Modified: 2026-03-25
CVE-2025-71081
In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: sai: fix OF node leak on probe The reference taken to the sync provider OF node when probing the platform device is currently only dropped if the set_sync() callback fails during DAI probe. Make sure to drop the reference on platform probe failures (e.g. probe deferral) and on driver unbind. This also avoids a potential use-after-free in case the DAI is ever reprobed without first rebinding the platform driver.
- https://git.kernel.org/stable/c/23261f0de09427367e99f39f588e31e2856a690e
- https://git.kernel.org/stable/c/3752afcc6d80d5525e236e329895ba2cb93bcb26
- https://git.kernel.org/stable/c/4054a3597d047f3fe87864ef87f399b5d523e6c0
- https://git.kernel.org/stable/c/7daa50a2157e41c964b745ab1dc378b5b3b626d1
- https://git.kernel.org/stable/c/acda653169e180b1d860dbb6bc5aceb105858394
- https://git.kernel.org/stable/c/bae74771fc5d3b2a9cf6f5aa64596083d032c4a3
Modified: 2026-03-25
CVE-2025-71082
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: revert use of devm_kzalloc in btusb This reverts commit 98921dbd00c4e ("Bluetooth: Use devm_kzalloc in btusb.c file"). In btusb_probe(), we use devm_kzalloc() to allocate the btusb data. This ties the lifetime of all the btusb data to the binding of a driver to one interface, INTF. In a driver that binds to other interfaces, ISOC and DIAG, this is an accident waiting to happen. The issue is revealed in btusb_disconnect(), where calling usb_driver_release_interface(&btusb_driver, data->intf) will have devm free the data that is also being used by the other interfaces of the driver that may not be released yet. To fix this, revert the use of devm and go back to freeing memory explicitly.
- https://git.kernel.org/stable/c/1e54c19eaf84ba652c4e376571093e58e144b339
- https://git.kernel.org/stable/c/252714f1e8bdd542025b16321c790458014d6880
- https://git.kernel.org/stable/c/c0ecb3e4451fe94f4315e6d09c4046dfbc42090b
- https://git.kernel.org/stable/c/cca0e9206e3bcc63cd3e72193e60149165d493cc
- https://git.kernel.org/stable/c/fdf7c640fb8a44a59b0671143d8c2f738bc48003
- https://git.kernel.org/stable/c/fff9206b0907252a41eb12b7c1407b9347df18b1
Modified: 2026-03-25
CVE-2025-71083
In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Avoid NULL pointer deref for evicted BOs It is possible for a BO to exist that is not currently associated with a resource, e.g. because it has been evicted. When devcoredump tries to read the contents of all BOs for dumping, we need to expect this as well -- in this case, ENODATA is recorded instead of the buffer contents.
- https://git.kernel.org/stable/c/3d004f7341d4898889801ebb2ef61ffca610dd6f
- https://git.kernel.org/stable/c/47a85604a761005d255ae38115ee630cc6931756
- https://git.kernel.org/stable/c/491adc6a0f9903c32b05f284df1148de39e8e644
- https://git.kernel.org/stable/c/4b9944493c6d92d7b29cfd83aaf3deb842b8da79
- https://git.kernel.org/stable/c/5a81095d3e1b521ac7cfe3b14d5f149bace3d6e0
- https://git.kernel.org/stable/c/b94182b3d7228aec18d069cba56d5982e9bfe1b1
Modified: 2026-03-25
CVE-2025-71084
In the Linux kernel, the following vulnerability has been resolved: RDMA/cm: Fix leaking the multicast GID table reference If the CM ID is destroyed while the CM event for multicast creating is still queued the cancel_work_sync() will prevent the work from running which also prevents destroying the ah_attr. This leaks a refcount and triggers a WARN: GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886 Destroy the ah_attr after canceling the work, it is safe to call this twice.
- https://git.kernel.org/stable/c/3ba6d01c4b3c584264dc733c6a2ecc5bbc8e0bb5
- https://git.kernel.org/stable/c/57f3cb6c84159d12ba343574df2115fb18dd83ca
- https://git.kernel.org/stable/c/5cb34bb5fd726491b809efbeb5cfd63ae5bf9cf3
- https://git.kernel.org/stable/c/ab668a58c4a2ccb6d54add7a76f2f955d15d0196
- https://git.kernel.org/stable/c/abf38398724ecc888f62c678d288da40d11878af
- https://git.kernel.org/stable/c/c0acdee513239e1d6e1b490f56be0e6837dfd162
- https://git.kernel.org/stable/c/d5ce588a9552878859a4d44b70b724216c188a5f
Modified: 2026-03-25
CVE-2025-71085
In the Linux kernel, the following vulnerability has been resolved: ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr() There exists a kernel oops caused by a BUG_ON(nhead < 0) at net/core/skbuff.c:2232 in pskb_expand_head(). This bug is triggered as part of the calipso_skbuff_setattr() routine when skb_cow() is passed headroom > INT_MAX (i.e. (int)(skb_headroom(skb) + len_delta) < 0). The root cause of the bug is due to an implicit integer cast in __skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensure that delta = headroom - skb_headroom(skb) is never negative, otherwise we will trigger a BUG_ON in pskb_expand_head(). However, if headroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, delta becomes negative, and pskb_expand_head() is passed a negative value for nhead. Fix the trigger condition in calipso_skbuff_setattr(). Avoid passing "negative" headroom sizes to skb_cow() within calipso_skbuff_setattr() by only using skb_cow() to grow headroom. PoC: Using `netlabelctl` tool: netlabelctl map del default netlabelctl calipso add pass doi:7 netlabelctl map add default address:0::1/128 protocol:calipso,7 Then run the following PoC: int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); // setup msghdr int cmsg_size = 2; int cmsg_len = 0x60; struct msghdr msg; struct sockaddr_in6 dest_addr; struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1, sizeof(struct cmsghdr) + cmsg_len); msg.msg_name = &dest_addr; msg.msg_namelen = sizeof(dest_addr); msg.msg_iov = NULL; msg.msg_iovlen = 0; msg.msg_control = cmsg; msg.msg_controllen = cmsg_len; msg.msg_flags = 0; // setup sockaddr dest_addr.sin6_family = AF_INET6; dest_addr.sin6_port = htons(31337); dest_addr.sin6_flowinfo = htonl(31337); dest_addr.sin6_addr = in6addr_loopback; dest_addr.sin6_scope_id = 31337; // setup cmsghdr cmsg->cmsg_len = cmsg_len; cmsg->cmsg_level = IPPROTO_IPV6; cmsg->cmsg_type = IPV6_HOPOPTS; char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr); hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80 sendmsg(fd, &msg, 0);
- https://git.kernel.org/stable/c/2bb759062efa188ea5d07242a43e5aa5464bbae1
- https://git.kernel.org/stable/c/58fc7342b529803d3c221101102fe913df7adb83
- https://git.kernel.org/stable/c/6b7522424529556c9cbc15e15e7bd4eeae310910
- https://git.kernel.org/stable/c/73744ad5696dce0e0f43872aba8de6a83d6ad570
- https://git.kernel.org/stable/c/86f365897068d09418488165a68b23cb5baa37f2
- https://git.kernel.org/stable/c/bf3709738d8a8cc6fa275773170c5c29511a0b24
- https://git.kernel.org/stable/c/c53aa6a5086f03f19564096ee084a202a8c738c0
Modified: 2026-03-25
CVE-2025-71086
In the Linux kernel, the following vulnerability has been resolved: net: rose: fix invalid array index in rose_kill_by_device() rose_kill_by_device() collects sockets into a local array[] and then iterates over them to disconnect sockets bound to a device being brought down. The loop mistakenly indexes array[cnt] instead of array[i]. For cnt < ARRAY_SIZE(array), this reads an uninitialized entry; for cnt == ARRAY_SIZE(array), it is an out-of-bounds read. Either case can lead to an invalid socket pointer dereference and also leaks references taken via sock_hold(). Fix the index to use i.
- https://git.kernel.org/stable/c/1418c12cd3bba79dc56b57b61c99efe40f579981
- https://git.kernel.org/stable/c/6595beb40fb0ec47223d3f6058ee40354694c8e4
- https://git.kernel.org/stable/c/819fb41ae54960f66025802400c9d3935eef4042
- https://git.kernel.org/stable/c/92d900aac3a5721fb54f3328f1e089b44a861c38
- https://git.kernel.org/stable/c/9f6185a32496834d6980b168cffcccc2d6b17280
- https://git.kernel.org/stable/c/b409ba9e1e63ccf3ab4cc061e33c1f804183543e
- https://git.kernel.org/stable/c/ed2639414d43ba037f798eaf619e878309310451
Modified: 2026-03-25
CVE-2025-71087
In the Linux kernel, the following vulnerability has been resolved:
iavf: fix off-by-one issues in iavf_config_rss_reg()
There are off-by-one bugs when configuring RSS hash key and lookup
table, causing out-of-bounds reads to memory [1] and out-of-bounds
writes to device registers.
Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"),
the loop upper bounds were:
i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX
which is safe since the value is the last valid index.
That commit changed the bounds to:
i <= adapter->rss_{key,lut}_size / 4
where `rss_{key,lut}_size / 4` is the number of dwords, so the last
valid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `<=`
accesses one element past the end.
Fix the issues by using `<` instead of `<=`, ensuring we do not exceed
the bounds.
[1] KASAN splat about rss_key_size off-by-one
BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800
Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63
CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: iavf iavf_watchdog_task
Call Trace:
- https://git.kernel.org/stable/c/18de0e41d69d97fab10b91fecf10ae78a5e43232
- https://git.kernel.org/stable/c/3095228e1320371e143835d0cebeef1a8a754c66
- https://git.kernel.org/stable/c/5bb18bfd505ca1affbca921462c350095a6c798c
- https://git.kernel.org/stable/c/6daa2893f323981c7894c68440823326e93a7d61
- https://git.kernel.org/stable/c/ceb8459df28d22c225a82d74c0f725f2a935d194
- https://git.kernel.org/stable/c/d7369dc8dd7cbf5cee3a22610028d847b6f02982
- https://git.kernel.org/stable/c/f36de3045d006e6d9be1be495f2ed88d1721e752
Modified: 2026-04-02
CVE-2025-71089
In the Linux kernel, the following vulnerability has been resolved: iommu: disable SVA when CONFIG_X86 is set Patch series "Fix stale IOTLB entries for kernel address space", v7. This proposes a fix for a security vulnerability related to IOMMU Shared Virtual Addressing (SVA). In an SVA context, an IOMMU can cache kernel page table entries. When a kernel page table page is freed and reallocated for another purpose, the IOMMU might still hold stale, incorrect entries. This can be exploited to cause a use-after-free or write-after-free condition, potentially leading to privilege escalation or data corruption. This solution introduces a deferred freeing mechanism for kernel page table pages, which provides a safe window to notify the IOMMU to invalidate its caches before the page is reused. This patch (of 8): In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware shares and walks the CPU's page tables. The x86 architecture maps the kernel's virtual address space into the upper portion of every process's page table. Consequently, in an SVA context, the IOMMU hardware can walk and cache kernel page table entries. The Linux kernel currently lacks a notification mechanism for kernel page table changes, specifically when page table pages are freed and reused. The IOMMU driver is only notified of changes to user virtual address mappings. This can cause the IOMMU's internal caches to retain stale entries for kernel VA. Use-After-Free (UAF) and Write-After-Free (WAF) conditions arise when kernel page table pages are freed and later reallocated. The IOMMU could misinterpret the new data as valid page table entries. The IOMMU might then walk into attacker-controlled memory, leading to arbitrary physical memory DMA access or privilege escalation. This is also a Write-After-Free issue, as the IOMMU will potentially continue to write Accessed and Dirty bits to the freed memory while attempting to walk the stale page tables. Currently, SVA contexts are unprivileged and cannot access kernel mappings. However, the IOMMU will still walk kernel-only page tables all the way down to the leaf entries, where it realizes the mapping is for the kernel and errors out. This means the IOMMU still caches these intermediate page table entries, making the described vulnerability a real concern. Disable SVA on x86 architecture until the IOMMU can receive notification to flush the paging cache before freeing the CPU kernel page table pages.
- https://git.kernel.org/stable/c/240cd7f2812cc25496b12063d11c823618f364e9
- https://git.kernel.org/stable/c/72f98ef9a4be30d2a60136dd6faee376f780d06c
- https://git.kernel.org/stable/c/7cad37e358970af1bb49030ff01f06a69fa7d985
- https://git.kernel.org/stable/c/b34289505180a83607fcfdce14b5a290d0528476
- https://git.kernel.org/stable/c/c2c3f1a3fd74ef16cf115f0c558616a13a8471b4
- https://git.kernel.org/stable/c/c341dee80b5df49a936182341b36395c831c2661
Modified: 2026-03-25
CVE-2025-71091
In the Linux kernel, the following vulnerability has been resolved:
team: fix check for port enabled in team_queue_override_port_prio_changed()
There has been a syzkaller bug reported recently with the following
trace:
list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122)
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:59!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59
Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff
RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286
RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000
RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005
RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230
R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480
FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0
Call Trace:
- https://git.kernel.org/stable/c/107d245f84cb4f55f597d31eda34b42a2b7d6952
- https://git.kernel.org/stable/c/25029e813c4aae5fcf7118e8dd5c56e382b9a1a3
- https://git.kernel.org/stable/c/53a727a8bfd78c739e130a781192d0f6f8e03d39
- https://git.kernel.org/stable/c/6bfb62b6010a16112dcae52f490e5e0e6abe12a3
- https://git.kernel.org/stable/c/932ac51d9953eaf77a1252f79b656d4ca86163c6
- https://git.kernel.org/stable/c/b71187648ef2349254673d0523fdf96d1fe3d758
- https://git.kernel.org/stable/c/f820e438b8ec2a8354e70e75145f05fe45500d97
Modified: 2026-03-25
CVE-2025-71093
In the Linux kernel, the following vulnerability has been resolved:
e1000: fix OOB in e1000_tbi_should_accept()
In e1000_tbi_should_accept() we read the last byte of the frame via
'data[length - 1]' to evaluate the TBI workaround. If the descriptor-
reported length is zero or larger than the actual RX buffer size, this
read goes out of bounds and can hit unrelated slab objects. The issue
is observed from the NAPI receive path (e1000_clean_rx_irq):
==================================================================
BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790
Read of size 1 at addr ffff888014114e54 by task sshd/363
CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/26c8bebc2f25288c2bcac7bc0a7662279a0e817c
- https://git.kernel.org/stable/c/278b7cfe0d4da7502c7fd679b15032f014c92892
- https://git.kernel.org/stable/c/2c4c0c09f9648ba766d399917d420d03e7b3e1f8
- https://git.kernel.org/stable/c/4ccfa56f272241e8d8e2c38191fdbb03df489d80
- https://git.kernel.org/stable/c/9c72a5182ed92904d01057f208c390a303f00a0f
- https://git.kernel.org/stable/c/ad7a2a45e2417ac54089926b520924f8f0d91aea
- https://git.kernel.org/stable/c/ee7c125fb3e8b04dd46510130b9fc92380e5d578
Modified: 2026-03-25
CVE-2025-71094
In the Linux kernel, the following vulnerability has been resolved: net: usb: asix: validate PHY address before use The ASIX driver reads the PHY address from the USB device via asix_read_phy_addr(). A malicious or faulty device can return an invalid address (>= PHY_MAX_ADDR), which causes a warning in mdiobus_get_phy(): addr 207 out of range WARNING: drivers/net/phy/mdio_bus.c:76 Validate the PHY address in asix_read_phy_addr() and remove the now-redundant check in ax88172a.c.
- https://git.kernel.org/stable/c/38722e69ee64dbb020028c93898d25d6f4c0e0b2
- https://git.kernel.org/stable/c/98a12c2547a44a5f03f35c108d2022cc652cbc4d
- https://git.kernel.org/stable/c/a1e077a3f76eea0dc671ed6792e7d543946227e8
- https://git.kernel.org/stable/c/bf8a0f3b787ca7c5889bfca12c60c483041fbee3
- https://git.kernel.org/stable/c/f5f4f30f3811d37e1aa48667c36add74e5a8d99f
- https://git.kernel.org/stable/c/fc96018f09f8d30586ca6582c5045a84eafef146
Modified: 2026-03-25
CVE-2025-71095
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix the crash issue for zero copy XDP_TX action There is a crash issue when running zero copy XDP_TX action, the crash log is shown below. [ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000 [ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP [ 216.301694] Call trace: [ 216.304130] dcache_clean_poc+0x20/0x38 (P) [ 216.308308] __dma_sync_single_for_device+0x1bc/0x1e0 [ 216.313351] stmmac_xdp_xmit_xdpf+0x354/0x400 [ 216.317701] __stmmac_xdp_run_prog+0x164/0x368 [ 216.322139] stmmac_napi_poll_rxtx+0xba8/0xf00 [ 216.326576] __napi_poll+0x40/0x218 [ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interrupt For XDP_TX action, the xdp_buff is converted to xdp_frame by xdp_convert_buff_to_frame(). The memory type of the resulting xdp_frame depends on the memory type of the xdp_buff. For page pool based xdp_buff it produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copy XSK pool based xdp_buff it produces xdp_frame with memory type MEM_TYPE_PAGE_ORDER0. However, stmmac_xdp_xmit_back() does not check the memory type and always uses the page pool type, this leads to invalid mappings and causes the crash. Therefore, check the xdp_buff memory type in stmmac_xdp_xmit_back() to fix this issue.
- https://git.kernel.org/stable/c/3f7823219407f2f18044c2b72366a48810c5c821
- https://git.kernel.org/stable/c/45ee0462b88396a0bd1df1991f801c89994ea72b
- https://git.kernel.org/stable/c/4d0ceb7677e1c4616afb96abb4518f70b65abb0d
- https://git.kernel.org/stable/c/5e5988736a95b1de7f91b10ac2575454b70e4897
- https://git.kernel.org/stable/c/a48e232210009be50591fdea8ba7c07b0f566a13
Modified: 2026-03-25
CVE-2025-71096
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctly The netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have a LS_NLA_TYPE_DGID attribute, it is invalid if it does not. Use the nl parsing logic properly and call nla_parse_deprecated() to fill the nlattrs array and then directly index that array to get the data for the DGID. Just fail if it is NULL. Remove the for loop searching for the nla, and squash the validation and parsing into one function. Fixes an uninitialized read from the stack triggered by userspace if it does not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVE query. BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline] BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 hex_byte_pack include/linux/hex.h:13 [inline] ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509 ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633 pointer+0xc09/0x1bd0 lib/vsprintf.c:2542 vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930 vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279 vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426 vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465 vprintk+0x36/0x50 kernel/printk/printk_safe.c:82 _printk+0x17e/0x1b0 kernel/printk/printk.c:2475 ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline] ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141 rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline] rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x333/0x3d0 net/socket.c:729 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671 __sys_sendmsg+0x1aa/0x300 net/socket.c:2703 __compat_sys_sendmsg net/compat.c:346 [inline] __do_compat_sys_sendmsg net/compat.c:353 [inline] __se_compat_sys_sendmsg net/compat.c:350 [inline] __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350 ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3
- https://git.kernel.org/stable/c/0b948afc1ded88b3562c893114387f34389eeb94
- https://git.kernel.org/stable/c/376f46c8983458ead26cac83aa897a0b78491831
- https://git.kernel.org/stable/c/45532638de5da24c201aa2a9b3dd4b054064de7b
- https://git.kernel.org/stable/c/9d85524789c2f17c0e87de8d596bcccc3683a1fc
- https://git.kernel.org/stable/c/a7b8e876e0ef0232b8076972c57ce9a7286b47ca
- https://git.kernel.org/stable/c/acadd4097d25d6bd472bcb3f9f3eba2b5105d1ec
- https://git.kernel.org/stable/c/bfe10318fc23e0b3f1d0a18dad387d29473a624d
Modified: 2026-03-25
CVE-2025-71097
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix reference count leak when using error routes with nexthop objects When a nexthop object is deleted, it is marked as dead and then fib_table_flush() is called to flush all the routes that are using the dead nexthop. The current logic in fib_table_flush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flush_all=true). Therefore, error routes are not flushed when their nexthop object is deleted: # ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1 As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak: # ip link del dev dummy1 [ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2 Fix by flushing error routes when their nexthop is marked as dead. IPv6 does not suffer from this problem.
- https://git.kernel.org/stable/c/30386e090c49e803c0616a7147e43409c32a2b0e
- https://git.kernel.org/stable/c/33ff5c207c873215e54e6176624ed57423cb7dea
- https://git.kernel.org/stable/c/5979338c83012110ccd45cae6517591770bfe536
- https://git.kernel.org/stable/c/5de7ad7e18356e39e8fbf7edd185a5faaf4f385a
- https://git.kernel.org/stable/c/ac782f4e3bfcde145b8a7f8af31d9422d94d172a
- https://git.kernel.org/stable/c/e3fc381320d04e4a74311e576a86cac49a16fc43
- https://git.kernel.org/stable/c/ee4183501ea556dca31f5ffd8690aa9fd25b609f
Modified: 2026-03-25
CVE-2025-71098
In the Linux kernel, the following vulnerability has been resolved:
ip6_gre: make ip6gre_header() robust
Over the years, syzbot found many ways to crash the kernel
in ip6gre_header() [1].
This involves team or bonding drivers ability to dynamically
change their dev->needed_headroom and/or dev->hard_header_len
In this particular crash mld_newpack() allocated an skb
with a too small reserve/headroom, and by the time mld_sendpack()
was called, syzbot managed to attach an ip6gre device.
[1]
skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:213 !
- https://git.kernel.org/stable/c/1717357007db150c2d703f13f5695460e960f26c
- https://git.kernel.org/stable/c/17e7386234f740f3e7d5e58a47b5847ea34c3bc2
- https://git.kernel.org/stable/c/41a1a3140aff295dee8063906f70a514548105e8
- https://git.kernel.org/stable/c/5fe210533e3459197eabfdbf97327dacbdc04d60
- https://git.kernel.org/stable/c/91a2b25be07ce1a7549ceebbe82017551d2eec92
- https://git.kernel.org/stable/c/adee129db814474f2f81207bd182bf343832a52e
- https://git.kernel.org/stable/c/db5b4e39c4e63700c68a7e65fc4e1f1375273476
Modified: 2026-03-25
CVE-2025-71099
In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix potential UAF in xe_oa_add_config_ioctl() In xe_oa_add_config_ioctl(), we accessed oa_config->id after dropping metrics_lock. Since this lock protects the lifetime of oa_config, an attacker could guess the id and call xe_oa_remove_config_ioctl() with perfect timing, freeing oa_config before we dereference it, leading to a potential use-after-free. Fix this by caching the id in a local variable while holding the lock. v2: (Matt A) - Dropped mutex_unlock(&oa->metrics_lock) ordering change from xe_oa_remove_config_ioctl() (cherry picked from commit 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31)
Modified: 2026-03-25
CVE-2025-71100
In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cu_tx_fill_desc() TID getting from ieee80211_get_tid() might be out of range of array size of sta_entry->tids[], so check TID is less than MAX_TID_COUNT. Othwerwise, UBSAN warn: UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30 index 10 is out of range for type 'rtl_tid_data [9]'
Modified: 2026-03-25
CVE-2025-71101
In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: Fix out-of-bounds array access in ACPI package parsing The hp_populate_*_elements_from_package() functions in the hp-bioscfg driver contain out-of-bounds array access vulnerabilities. These functions parse ACPI packages into internal data structures using a for loop with index variable 'elem' that iterates through enum_obj/integer_obj/order_obj/password_obj/string_obj arrays. When processing multi-element fields like PREREQUISITES and ENUM_POSSIBLE_VALUES, these functions read multiple consecutive array elements using expressions like 'enum_obj[elem + reqs]' and 'enum_obj[elem + pos_values]' within nested loops. The bug is that the bounds check only validated elem, but did not consider the additional offset when accessing elem + reqs or elem + pos_values. The fix changes the bounds check to validate the actual accessed index.
Modified: 2026-03-25
CVE-2025-71102
In the Linux kernel, the following vulnerability has been resolved: scs: fix a wrong parameter in __scs_magic __scs_magic() needs a 'void *' variable, but a 'struct task_struct *' is given. 'task_scs(tsk)' is the starting address of the task's shadow call stack, and '__scs_magic(task_scs(tsk))' is the end address of the task's shadow call stack. Here should be '__scs_magic(task_scs(tsk))'. The user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGE is enabled, the shadow call stack usage checking function (scs_check_usage) would scan an incorrect memory range. This could lead 1. **Inaccurate stack usage reporting**: The function would calculate wrong usage statistics for the shadow call stack, potentially showing incorrect value in kmsg. 2. **Potential kernel crash**: If the value of __scs_magic(tsk)is greater than that of __scs_magic(task_scs(tsk)), the for loop may access unmapped memory, potentially causing a kernel panic. However, this scenario is unlikely because task_struct is allocated via the slab allocator (which typically returns lower addresses), while the shadow call stack returned by task_scs(tsk) is allocated via vmalloc(which typically returns higher addresses). However, since this is purely a debugging feature (CONFIG_DEBUG_STACK_USAGE), normal production systems should be not unaffected. The bug only impacts developers and testers who are actively debugging stack usage with this configuration enabled.
- https://git.kernel.org/stable/c/062774439d442882b44f5eab8c256ad3423ef284
- https://git.kernel.org/stable/c/08bd4c46d5e63b78e77f2605283874bbe868ab19
- https://git.kernel.org/stable/c/1727e8bd69103a68963a5613a0ddb6d8d37df5d3
- https://git.kernel.org/stable/c/57ba40b001be27786d0570dd292289df748b306b
- https://git.kernel.org/stable/c/9ef28943471a16e4f9646bc3e8e2de148e7d8d7b
- https://git.kernel.org/stable/c/a19fb3611e4c06624fc0f83ef19f4fb8d57d4751
- https://git.kernel.org/stable/c/cfdf6250b63b953b1d8e60814c8ca96c6f9d1c8c
Modified: 2026-03-25
CVE-2025-71104
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer
When advancing the target expiration for the guest's APIC timer in periodic
mode, set the expiration to "now" if the target expiration is in the past
(similar to what is done in update_target_expiration()). Blindly adding
the period to the previous target expiration can result in KVM generating
a practically unbounded number of hrtimer IRQs due to programming an
expired timer over and over. In extreme scenarios, e.g. if userspace
pauses/suspends a VM for an extended duration, this can even cause hard
lockups in the host.
Currently, the bug only affects Intel CPUs when using the hypervisor timer
(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,
a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the
HV timer only runs while the guest is active. As a result, if the vCPU
does not run for an extended duration, there will be a huge gap between
the target expiration and the current time the vCPU resumes running.
Because the target expiration is incremented by only one period on each
timer expiration, this leads to a series of timer expirations occurring
rapidly after the vCPU/VM resumes.
More critically, when the vCPU first triggers a periodic HV timer
expiration after resuming, advancing the expiration by only one period
will result in a target expiration in the past. As a result, the delta
may be calculated as a negative value. When the delta is converted into
an absolute value (tscdeadline is an unsigned u64), the resulting value
can overflow what the HV timer is capable of programming. I.e. the large
value will exceed the VMX Preemption Timer's maximum bit width of
cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the
HV timer to the software timer (hrtimers).
After switching to the software timer, periodic timer expiration callbacks
may be executed consecutively within a single clock interrupt handler,
because hrtimers honors KVM's request for an expiration in the past and
immediately re-invokes KVM's callback after reprogramming. And because
the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer
over and over until the target expiration is advanced to "now" can result
in a hard lockup.
E.g. the following hard lockup was triggered in the host when running a
Windows VM (only relevant because it used the APIC timer in periodic mode)
after resuming the VM from a long suspend (in the host).
NMI watchdog: Watchdog detected hard LOCKUP on cpu 45
...
RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]
...
RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046
RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc
RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500
RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0
R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0
R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8
FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/18ab3fc8e880791aa9f7c000261320fc812b5465
- https://git.kernel.org/stable/c/786ed625c125c5cd180d6aaa37e653e3e4ffb8d9
- https://git.kernel.org/stable/c/7b54ccef865e0aa62e4871d4ada2ba4b9dcb8bed
- https://git.kernel.org/stable/c/807dbe8f3862fa7c164155857550ce94b36a11b9
- https://git.kernel.org/stable/c/d2da0df7bbc4fb4fd7d0a1da704f81a09c72fe73
- https://git.kernel.org/stable/c/e23f46f1a971c73dad2fd63e1408696114ddebe2
- https://git.kernel.org/stable/c/e746e51947053a02af2ea964593dc4887108d379
Modified: 2026-03-25
CVE-2025-71105
In the Linux kernel, the following vulnerability has been resolved: f2fs: use global inline_xattr_slab instead of per-sb slab cache As Hong Yun reported in mailing list: loop7: detected capacity change from 0 to 131072 ------------[ cut here ]------------ kmem_cache of name 'f2fs_xattr_entry-7:7' already exists WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline] WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307 CPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 Not tainted 6.17.0-rc4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline] RIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307 Call Trace: __kmem_cache_create include/linux/slab.h:353 [inline] f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline] f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843 f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918 get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692 vfs_get_tree+0x43/0x140 fs/super.c:1815 do_new_mount+0x201/0x550 fs/namespace.c:3808 do_mount fs/namespace.c:4136 [inline] __do_sys_mount fs/namespace.c:4347 [inline] __se_sys_mount+0x298/0x2f0 fs/namespace.c:4324 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e The bug can be reproduced w/ below scripts: - mount /dev/vdb /mnt1 - mount /dev/vdc /mnt2 - umount /mnt1 - mounnt /dev/vdb /mnt1 The reason is if we created two slab caches, named f2fs_xattr_entry-7:3 and f2fs_xattr_entry-7:7, and they have the same slab size. Actually, slab system will only create one slab cache core structure which has slab name of "f2fs_xattr_entry-7:3", and two slab caches share the same structure and cache address. So, if we destroy f2fs_xattr_entry-7:3 cache w/ cache address, it will decrease reference count of slab cache, rather than release slab cache entirely, since there is one more user has referenced the cache. Then, if we try to create slab cache w/ name "f2fs_xattr_entry-7:3" again, slab system will find that there is existed cache which has the same name and trigger the warning. Let's changes to use global inline_xattr_slab instead of per-sb slab cache for fixing.
- https://git.kernel.org/stable/c/1eb0b130196bcbc56c5c80c83139fa70c0aa82c5
- https://git.kernel.org/stable/c/1f27ef42bb0b7c0740c5616ec577ec188b8a1d05
- https://git.kernel.org/stable/c/474cc3ed37436ddfd63cac8dbffe3b1e219e9100
- https://git.kernel.org/stable/c/72ce19dfed162da6e430467333b2da70471d08a4
- https://git.kernel.org/stable/c/93d30fe19660dec6bf1bd3d5c186c1c737b21aa5
- https://git.kernel.org/stable/c/be4c3a3c6c2304a8fcd14095d18d26f0cc4e222a
- https://git.kernel.org/stable/c/e6d828eae00ec192e18c2ddaa2fd32050a96048a
Modified: 2026-03-25
CVE-2025-71107
In the Linux kernel, the following vulnerability has been resolved:
f2fs: ensure node page reads complete before f2fs_put_super() finishes
Xfstests generic/335, generic/336 sometimes crash with the following message:
F2FS-fs (dm-0): detect filesystem reference count leak during umount, type: 9, count: 1
------------[ cut here ]------------
kernel BUG at fs/f2fs/super.c:1939!
Oops: invalid opcode: 0000 [#1] SMP NOPTI
CPU: 1 UID: 0 PID: 609351 Comm: umount Tainted: G W 6.17.0-rc5-xfstests-g9dd1835ecda5 #1 PREEMPT(none)
Tainted: [W]=WARN
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:f2fs_put_super+0x3b3/0x3c0
Call Trace:
Modified: 2026-03-25
CVE-2025-71108
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Handle incorrect num_connectors capability The UCSI spec states that the num_connectors field is 7 bits, and the 8th bit is reserved and should be set to zero. Some buggy FW has been known to set this bit, and it can lead to a system not booting. Flag that the FW is not behaving correctly, and auto-fix the value so that the system boots correctly. Found on Lenovo P1 G8 during Linux enablement program. The FW will be fixed, but seemed worth addressing in case it hit platforms that aren't officially Linux supported.
- https://git.kernel.org/stable/c/07c8d2a109d847775b3b4e2c3294c8e1eea75432
- https://git.kernel.org/stable/c/132fe187e0d940f388f839fe2cde9b84106ad20d
- https://git.kernel.org/stable/c/3042a57a8e8bce4a3100c3f6f03dc372aab24943
- https://git.kernel.org/stable/c/30cd2cb1abf4c4acdb1ddb468c946f68939819fb
- https://git.kernel.org/stable/c/58941bbb0050e365a98c64f1fc4a9a0ac127dba6
- https://git.kernel.org/stable/c/914605b0de8128434eafc9582445306830748b93
- https://git.kernel.org/stable/c/f72f97d0aee4a993a35f2496bca5efd24827235d
Modified: 2026-03-25
CVE-2025-71109
In the Linux kernel, the following vulnerability has been resolved: MIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits Since commit e424054000878 ("MIPS: Tracing: Reduce the overhead of dynamic Function Tracer"), the macro UASM_i_LA_mostly has been used, and this macro can generate more than 2 instructions. At the same time, the code in ftrace assumes that no more than 2 instructions can be generated, which is why it stores them in an int[2] array. However, as previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA) causes a buffer overflow when _mcount is beyond 32 bits. This leads to corruption of the variables located in the __read_mostly section. This corruption was observed because the variable __cpu_primary_thread_mask was corrupted, causing a hang very early during boot. This fix prevents the corruption by avoiding the generation of instructions if they could exceed 2 instructions in length. Fortunately, insn_la_mcount is only used if the instrumented code is located outside the kernel code section, so dynamic ftrace can still be used, albeit in a more limited scope. This is still preferable to corrupting memory and/or crashing the kernel.
Modified: 2026-03-25
CVE-2025-71111
In the Linux kernel, the following vulnerability has been resolved: hwmon: (w83791d) Convert macros to functions to avoid TOCTOU The macro FAN_FROM_REG evaluates its arguments multiple times. When used in lockless contexts involving shared driver data, this leads to Time-of-Check to Time-of-Use (TOCTOU) race conditions, potentially causing divide-by-zero errors. Convert the macro to a static function. This guarantees that arguments are evaluated only once (pass-by-value), preventing the race conditions. Additionally, in store_fan_div, move the calculation of the minimum limit inside the update lock. This ensures that the read-modify-write sequence operates on consistent data. Adhere to the principle of minimal changes by only converting macros that evaluate arguments multiple times and are used in lockless contexts.
- https://git.kernel.org/stable/c/3dceb68f6ad33156032ef4da21a93d84059cca6d
- https://git.kernel.org/stable/c/670d7ef945d3a84683594429aea6ab2cdfa5ceb4
- https://git.kernel.org/stable/c/a9fb6e8835a22f5796c1182ed612daed3fd273af
- https://git.kernel.org/stable/c/bf5b03227f2e6d4360004886d268f9df8993ef8f
- https://git.kernel.org/stable/c/c8cf0c2bdcccc6634b6915ff793b844e12436680
- https://git.kernel.org/stable/c/f2b579a0c37c0df19603d719894a942a295f634a
- https://git.kernel.org/stable/c/f94800fbc26ccf7c81eb791707b038a57aa39a18
Modified: 2026-03-25
CVE-2025-71112
In the Linux kernel, the following vulnerability has been resolved: net: hns3: add VLAN id validation before using Currently, the VLAN id may be used without validation when receive a VLAN configuration mailbox from VF. The length of vlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause out-of-bounds memory access once the VLAN id is bigger than or equal to VLAN_N_VID. Therefore, VLAN id needs to be checked to ensure it is within the range of VLAN_N_VID.
- https://git.kernel.org/stable/c/00e56a7706e10b3d00a258d81fcb85a7e96372d6
- https://git.kernel.org/stable/c/42c91dfa772c57de141e5a55a187ac760c0fd7e1
- https://git.kernel.org/stable/c/46c7d9fe8dd869ea5de666aba8c1ec1061ca44a8
- https://git.kernel.org/stable/c/6ef935e65902bfed53980ad2754b06a284ea8ac1
- https://git.kernel.org/stable/c/91a51d01be5c9f82c12c2921ca5cceaa31b67128
- https://git.kernel.org/stable/c/95cca255a7a5ad782639ff0298c2a486707d1046
- https://git.kernel.org/stable/c/b7b4f3bf118f51b67691a55b464f04452e5dc6fc
Modified: 2026-03-25
CVE-2025-71113
In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - zero initialize memory allocated via sock_kmalloc Several crypto user API contexts and requests allocated with sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future. The ACVP patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on proper initialization of their context structures. A particular issue has been observed with the newly added 'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests") Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true: https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209 The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data.
- https://git.kernel.org/stable/c/51a5ab36084f3251ef87eda3e6a6236f6488925e
- https://git.kernel.org/stable/c/543bf004e4eafbb302b1e6c78570d425d2ca13a0
- https://git.kernel.org/stable/c/5a4b65523608974a81edbe386f8a667a3e10c726
- https://git.kernel.org/stable/c/6f6e309328d53a10c0fe1f77dec2db73373179b6
- https://git.kernel.org/stable/c/84238876e3b3b262cf62d5f4d1338e983fb27010
- https://git.kernel.org/stable/c/e125c8e346e4eb7b3e854c862fcb4392bc13ddba
- https://git.kernel.org/stable/c/f81244fd6b14fecfa93b66b6bb1d59f96554e550
Modified: 2026-03-25
CVE-2025-71114
In the Linux kernel, the following vulnerability has been resolved:
via_wdt: fix critical boot hang due to unnamed resource allocation
The VIA watchdog driver uses allocate_resource() to reserve a MMIO
region for the watchdog control register. However, the allocated
resource was not given a name, which causes the kernel resource tree
to contain an entry marked as "
- https://git.kernel.org/stable/c/1d56025a3af50db0f3da2792f41eb9943eee5324
- https://git.kernel.org/stable/c/47c910965c936724070d2a8094a4c3ed8f452856
- https://git.kernel.org/stable/c/7aa31ee9ec92915926e74731378c009c9cc04928
- https://git.kernel.org/stable/c/c6a2dd4f2e4e6cbdfe7a1618160281af897b75db
- https://git.kernel.org/stable/c/c7b986adc9e9336066350542ac5a2005d305ae78
- https://git.kernel.org/stable/c/d2c7c90aca7b37f60f16b2bedcfeb16204f2f35d
- https://git.kernel.org/stable/c/f7b6370d0fbee06a867037d675797a606cb62e57
Modified: 2026-03-25
CVE-2025-71116
In the Linux kernel, the following vulnerability has been resolved: libceph: make decode_pool() more resilient against corrupted osdmaps If the osdmap is (maliciously) corrupted such that the encoded length of ceph_pg_pool envelope is less than what is expected for a particular encoding version, out-of-bounds reads may ensue because the only bounds check that is there is based on that length value. This patch adds explicit bounds checks for each field that is decoded or skipped.
- https://git.kernel.org/stable/c/145d140abda80e33331c5781d6603014fa75d258
- https://git.kernel.org/stable/c/2acb8517429ab42146c6c0ac1daed1f03d2fd125
- https://git.kernel.org/stable/c/5d0d8c292531fe356c4e94dcfdf7d7212aca9957
- https://git.kernel.org/stable/c/8c738512714e8c0aa18f8a10c072d5b01c83db39
- https://git.kernel.org/stable/c/c82e39ff67353a5a6cbc07b786b8690bd2c45aaa
- https://git.kernel.org/stable/c/d061be4c8040ffb1110d537654a038b8b6ad39d2
- https://git.kernel.org/stable/c/e927ab132b87ba3f076705fc2684d94b24201ed1
Modified: 2026-03-25
CVE-2025-71118
In the Linux kernel, the following vulnerability has been resolved: ACPICA: Avoid walking the Namespace if start_node is NULL Although commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespace if it is not there") fixed the situation when both start_node and acpi_gbl_root_node are NULL, the Linux kernel mainline now still crashed on Honor Magicbook 14 Pro [1]. That happens due to the access to the member of parent_node in acpi_ns_get_next_node(). The NULL pointer dereference will always happen, no matter whether or not the start_node is equal to ACPI_ROOT_OBJECT, so move the check of start_node being NULL out of the if block. Unfortunately, all the attempts to contact Honor have failed, they refused to provide any technical support for Linux. The bad DSDT table's dump could be found on GitHub [2]. DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025 [ rjw: Subject adjustment, changelog edits ]
- https://git.kernel.org/stable/c/0d8bb08126920fd4b12dbf32d9250757c9064b36
- https://git.kernel.org/stable/c/1bc34293dfbd266c29875206849b4f8e8177e6df
- https://git.kernel.org/stable/c/7f9b951ed11842373851dd3c91860778356d62d3
- https://git.kernel.org/stable/c/9d6c58dae8f6590c746ac5d0012ffe14a77539f0
- https://git.kernel.org/stable/c/b84edef48cc8afb41150949a87dcfa81bc95b53e
- https://git.kernel.org/stable/c/ecb296286c8787895625bd4c53e9478db4ae139c
- https://git.kernel.org/stable/c/f91dad0a3b381244183ffbea4cec5a7a69d6f41e
Modified: 2026-03-25
CVE-2025-71119
In the Linux kernel, the following vulnerability has been resolved: powerpc/kexec: Enable SMT before waking offline CPUs If SMT is disabled or a partial SMT state is enabled, when a new kernel image is loaded for kexec, on reboot the following warning is observed: kexec: Waking offline cpu 228. WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc [snip] NIP kexec_prepare_cpus+0x1b0/0x1bc LR kexec_prepare_cpus+0x1a0/0x1bc Call Trace: kexec_prepare_cpus+0x1a0/0x1bc (unreliable) default_machine_kexec+0x160/0x19c machine_kexec+0x80/0x88 kernel_kexec+0xd0/0x118 __do_sys_reboot+0x210/0x2c4 system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec This occurs as add_cpu() fails due to cpu_bootable() returning false for CPUs that fail the cpu_smt_thread_allowed() check or non primary threads if SMT is disabled. Fix the issue by enabling SMT and resetting the number of SMT threads to the number of threads per core, before attempting to wake up all present CPUs.
- https://git.kernel.org/stable/c/0d5c9e901ad40bd39b38e119c0454b52d7663930
- https://git.kernel.org/stable/c/7cccd82a0e4aad192fd74fc60e61ed9aed5857a3
- https://git.kernel.org/stable/c/c2296a1e42418556efbeb5636c4fa6aa6106713a
- https://git.kernel.org/stable/c/d790ef0c4819424ee0c2f448c0a8154c5ca369d1
- https://git.kernel.org/stable/c/f0c0a681ffb77b8c5290c88c02d968199663939b
Modified: 2026-03-25
CVE-2025-71120
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf A zero length gss_token results in pages == 0 and in_token->pages[0] is NULL. The code unconditionally evaluates page_address(in_token->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.
- https://git.kernel.org/stable/c/1c8bb965e9b0559ff0f5690615a527c30f651dd8
- https://git.kernel.org/stable/c/4dedb6a11243a5c9eb9dbb97bca3c98bd725e83d
- https://git.kernel.org/stable/c/7452d53f293379e2c38cfa8ad0694aa46fc4788b
- https://git.kernel.org/stable/c/a2c6f25ab98b423f99ccd94874d655b8bcb01a19
- https://git.kernel.org/stable/c/a8f1e445ce3545c90d69c9e8ff8f7821825fe810
- https://git.kernel.org/stable/c/d4b69a6186b215d2dc1ebcab965ed88e8d41768d
- https://git.kernel.org/stable/c/f9e53f69ac3bc4ef568b08d3542edac02e83fefd
Modified: 2026-03-25
CVE-2025-71121
In the Linux kernel, the following vulnerability has been resolved: parisc: Do not reprogram affinitiy on ASP chip The ASP chip is a very old variant of the GSP chip and is used e.g. in HP 730 workstations. When trying to reprogram the affinity it will crash with a HPMC as the relevant registers don't seem to be at the usual location. Let's avoid the crash by checking the sversion. Also note, that reprogramming isn't necessary either, as the HP730 is a just a single-CPU machine.
- https://git.kernel.org/stable/c/4d0858bbeea12a50bfb32137f74d4b74917ebadd
- https://git.kernel.org/stable/c/60560d13ff368415c96a0c1247bea16d427c0641
- https://git.kernel.org/stable/c/7a146f34e5be96330467397c9fd9d3d851b2cbbe
- https://git.kernel.org/stable/c/845a92b74cf7a730200532ecb4482981cec9d006
- https://git.kernel.org/stable/c/c8f810e20f4bbe50b49f73429d9fa6efad00623e
- https://git.kernel.org/stable/c/dca7da244349eef4d78527cafc0bf80816b261f5
- https://git.kernel.org/stable/c/e09fd2eb6d4c993ee9eaae556cb51e30ec1042df
Modified: 2026-03-25
CVE-2025-71122
In the Linux kernel, the following vulnerability has been resolved: iommufd/selftest: Check for overflow in IOMMU_TEST_OP_ADD_RESERVED syzkaller found it could overflow math in the test infrastructure and cause a WARN_ON by corrupting the reserved interval tree. This only effects test kernels with CONFIG_IOMMUFD_TEST. Validate the user input length in the test ioctl.
Modified: 2026-03-25
CVE-2025-71123
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix string copying in parse_apply_sb_mount_options()
strscpy_pad() can't be used to copy a non-NUL-term string into a NUL-term
string of possibly bigger size. Commit 0efc5990bca5 ("string.h: Introduce
memtostr() and memtostr_pad()") provides additional information in that
regard. So if this happens, the following warning is observed:
strnlen: detected buffer overflow: 65 byte read of buffer size 64
WARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032
Modules linked in:
CPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032
Call Trace:
- https://git.kernel.org/stable/c/52ac96c4a2dd7bc47666000440b0602d9742e820
- https://git.kernel.org/stable/c/5bbacbbf1ca4419861dca3c6b82707c10e9c021c
- https://git.kernel.org/stable/c/6e37143560e37869d51b7d9e0ac61fc48895f8a0
- https://git.kernel.org/stable/c/902ca2356f1e3ec5355c5808ad5d3f9d0095b0cc
- https://git.kernel.org/stable/c/db9ee13fab0267eccf6544ee35b16c9522db9aac
- https://git.kernel.org/stable/c/ee5a977b4e771cc181f39d504426dbd31ed701cc
Modified: 2026-03-25
CVE-2025-71125
In the Linux kernel, the following vulnerability has been resolved:
tracing: Do not register unsupported perf events
Synthetic events currently do not have a function to register perf events.
This leads to calling the tracepoint register functions with a NULL
function pointer which triggers:
------------[ cut here ]------------
WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272
Modules linked in: kvm_intel kvm irqbypass
CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
RIP: 0010:tracepoint_add_func+0x357/0x370
Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f
RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246
RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000
RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8
RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780
R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a
R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78
FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0
Call Trace:
- https://git.kernel.org/stable/c/3437c775bf209c674ad66304213b6b3c3b1b3f69
- https://git.kernel.org/stable/c/65b1971147ec12f0b1cee0811c859a3d7d9b04ce
- https://git.kernel.org/stable/c/6819bc6285c0ff835f67cfae7efebc03541782f6
- https://git.kernel.org/stable/c/6d15f08e6d8d4b4fb02d90805ea97f3e2c1d6fbc
- https://git.kernel.org/stable/c/6df47e5bb9b62d72f186f826ab643ea1856877c7
- https://git.kernel.org/stable/c/ef7f38df890f5dcd2ae62f8dbde191d72f3bebae
- https://git.kernel.org/stable/c/f7305697b60d79bc69c0a6e280fc931b4e8862dd
Modified: 2026-03-25
CVE-2025-71126
In the Linux kernel, the following vulnerability has been resolved:
mptcp: avoid deadlock on fallback while reinjecting
Jakub reported an MPTCP deadlock at fallback time:
WARNING: possible recursive locking detected
6.18.0-rc7-virtme #1 Not tainted
--------------------------------------------
mptcp_connect/20858 is trying to acquire lock:
ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_try_fallback+0xd8/0x280
but task is already holding lock:
ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&msk->fallback_lock);
lock(&msk->fallback_lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by mptcp_connect/20858:
#0: ff1100001da18290 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_sendmsg+0x114/0x1bc0
#1: ff1100001db40fd0 (k-sk_lock-AF_INET#2){+.+.}-{0:0}, at: __mptcp_retrans+0x2cb/0xaa0
#2: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0
stack backtrace:
CPU: 0 UID: 0 PID: 20858 Comm: mptcp_connect Not tainted 6.18.0-rc7-virtme #1 PREEMPT(full)
Hardware name: Bochs, BIOS Bochs 01/01/2011
Call Trace:
- https://git.kernel.org/stable/c/0107442e82c0f8d6010e07e6030741c59c520d6e
- https://git.kernel.org/stable/c/0ca9fb4335e726dab4f23b3bfe87271d8f005f41
- https://git.kernel.org/stable/c/252892d5a6a2f163ce18f32716e46fa4da7d4e79
- https://git.kernel.org/stable/c/50f47c02be419bf0a3ae94c118addf67beef359f
- https://git.kernel.org/stable/c/ffb8c27b0539dd90262d1021488e7817fae57c42
Modified: 2026-03-25
CVE-2025-71129
In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Sign extend kfunc call arguments The kfunc calls are native calls so they should follow LoongArch calling conventions. Sign extend its arguments properly to avoid kernel panic. This is done by adding a new emit_abi_ext() helper. The emit_abi_ext() helper performs extension in place meaning a value already store in the target register (Note: this is different from the existing sign_extend() helper and thus we can't reuse it).
Modified: 2026-03-25
CVE-2025-71130
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer Initialize the eb.vma array with values of 0 when the eb structure is first set up. In particular, this sets the eb->vma[i].vma pointers to NULL, simplifying cleanup and getting rid of the bug described below. During the execution of eb_lookup_vmas(), the eb->vma array is successively filled up with struct eb_vma objects. This process includes calling eb_add_vma(), which might fail; however, even in the event of failure, eb->vma[i].vma is set for the currently processed buffer. If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which prompts a call to eb_release_vmas() to clean up the mess. Since eb_lookup_vmas() might fail during processing any (possibly not first) buffer, eb_release_vmas() checks whether a buffer's vma is NULL to know at what point did the lookup function fail. In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helper function eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma is set to NULL in case i915_gem_object_userptr_submit_init() fails; the current one needs to be cleaned up by eb_release_vmas() at this point, so the next one is set. If eb_add_vma() fails, neither the current nor the next vma is set to NULL, which is a source of a NULL deref bug described in the issue linked in the Closes tag. When entering eb_lookup_vmas(), the vma pointers are set to the slab poison value, instead of NULL. This doesn't matter for the actual lookup, since it gets overwritten anyway, however the eb_release_vmas() function only recognizes NULL as the stopping value, hence the pointers are being set to NULL as they go in case of intermediate failure. This patch changes the approach to filling them all with NULL at the start instead, rather than handling that manually during failure. (cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)
- https://git.kernel.org/stable/c/0336188cc85d0eab8463bd1bbd4ded4e9602de8b
- https://git.kernel.org/stable/c/24d55ac8e31d2f8197bfad71ffcb3bae21ed7117
- https://git.kernel.org/stable/c/25d69e07770745992387c016613fd7ac8eaf9893
- https://git.kernel.org/stable/c/4fe2bd195435e71c117983d87f278112c5ab364c
- https://git.kernel.org/stable/c/63f23aa2fbb823c8b15a29269fde220d227ce5b3
Modified: 2026-03-25
CVE-2025-71131
In the Linux kernel, the following vulnerability has been resolved: crypto: seqiv - Do not use req->iv after crypto_aead_encrypt As soon as crypto_aead_encrypt is called, the underlying request may be freed by an asynchronous completion. Thus dereferencing req->iv after it returns is invalid. Instead of checking req->iv against info, create a new variable unaligned_info and use it for that purpose instead.
- https://git.kernel.org/stable/c/0279978adec6f1296af66b642cce641c6580be46
- https://git.kernel.org/stable/c/18202537856e0fae079fed2c9308780bcff2bb9d
- https://git.kernel.org/stable/c/50f196d2bbaee4ab2494bb1b0d294deba292951a
- https://git.kernel.org/stable/c/50fdb78b7c0bcc550910ef69c0984e751cac72fa
- https://git.kernel.org/stable/c/5476f7f8a311236604b78fcc5b2a63b3a61b0169
- https://git.kernel.org/stable/c/baf0e2d1e03ddb04781dfe7f22a654d3611f69b2
- https://git.kernel.org/stable/c/ccbb96434d88e32358894c879457b33f7508e798
Modified: 2026-03-25
CVE-2025-71132
In the Linux kernel, the following vulnerability has been resolved: smc91x: fix broken irq-context in PREEMPT_RT When smc91x.c is built with PREEMPT_RT, the following splat occurs in FVP_RevC: [ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000 [ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106] [ 13.062137] preempt=0x00000000 lock=0->0 RCU=0->1 workfn=mld_ifc_work [ 13.062266] C ** replaying previous printk message ** [ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)} [ 13.062353] Hardware name: , BIOS [ 13.062382] Workqueue: mld mld_ifc_work [ 13.062469] Call trace: [ 13.062494] show_stack+0x24/0x40 (C) [ 13.062602] __dump_stack+0x28/0x48 [ 13.062710] dump_stack_lvl+0x7c/0xb0 [ 13.062818] dump_stack+0x18/0x34 [ 13.062926] process_scheduled_works+0x294/0x450 [ 13.063043] worker_thread+0x260/0x3d8 [ 13.063124] kthread+0x1c4/0x228 [ 13.063235] ret_from_fork+0x10/0x20 This happens because smc_special_trylock() disables IRQs even on PREEMPT_RT, but smc_special_unlock() does not restore IRQs on PREEMPT_RT. The reason is that smc_special_unlock() calls spin_unlock_irqrestore(), and rcu_read_unlock_bh() in __dev_queue_xmit() cannot invoke rcu_read_unlock() through __local_bh_enable_ip() when current->softirq_disable_cnt becomes zero. To address this issue, replace smc_special_trylock() with spin_trylock_irqsave().
- https://git.kernel.org/stable/c/1c4cb705e733250d13243f6a69b8b5a92e39b9f6
- https://git.kernel.org/stable/c/36561b86cb2501647662cfaf91286dd6973804a6
- https://git.kernel.org/stable/c/6402078bd9d1ed46e79465e1faaa42e3458f8a33
- https://git.kernel.org/stable/c/9d222141b00156509d67d80c771fbefa92c43ace
- https://git.kernel.org/stable/c/b6018d5c1a8f09d5efe4d6961d7ee45fdf3a7ce3
- https://git.kernel.org/stable/c/ef277ae121b3249c99994652210a326b52d527b0
Modified: 2026-03-25
CVE-2025-71133
In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: avoid invalid read in irdma_net_event
irdma_net_event() should not dereference anything from "neigh" (alias
"ptr") until it has checked that the event is NETEVENT_NEIGH_UPDATE.
Other events come with different structures pointed to by "ptr" and they
may be smaller than struct neighbour.
Move the read of neigh->dev under the NETEVENT_NEIGH_UPDATE case.
The bug is mostly harmless, but it triggers KASAN on debug kernels:
BUG: KASAN: stack-out-of-bounds in irdma_net_event+0x32e/0x3b0 [irdma]
Read of size 8 at addr ffffc900075e07f0 by task kworker/27:2/542554
CPU: 27 PID: 542554 Comm: kworker/27:2 Kdump: loaded Not tainted 5.14.0-630.el9.x86_64+debug #1
Hardware name: [...]
Workqueue: events rt6_probe_deferred
Call Trace:
- https://git.kernel.org/stable/c/305c02e541befe4a44ffde30ed374970f41aeb6c
- https://git.kernel.org/stable/c/6f05611728e9d0ab024832a4f1abb74a5f5d0bb0
- https://git.kernel.org/stable/c/bf197c7c79ef6458d1ee84dd7db251b51784885f
- https://git.kernel.org/stable/c/d9b9affd103f51b42322da4ed5ac025b560bc354
- https://git.kernel.org/stable/c/db93ae6fa66f1c61ae63400191195e3ee58021da
- https://git.kernel.org/stable/c/fc23d05f0b3fb4d80657e7afebae2cae686b31c8
Modified: 2026-03-25
CVE-2025-71135
In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix possible null-pointer dereferences in raid5_store_group_thread_cnt() The variable mddev->private is first assigned to conf and then checked: conf = mddev->private; if (!conf) ... If conf is NULL, then mddev->private is also NULL. In this case, null-pointer dereferences can occur when calling raid5_quiesce(): raid5_quiesce(mddev, true); raid5_quiesce(mddev, false); since mddev->private is assigned to conf again in raid5_quiesce(), and conf is dereferenced in several places, for example: conf->quiesce = 0; wake_up(&conf->wait_for_quiescent); To fix this issue, the function should unlock mddev and return before invoking raid5_quiesce() when conf is NULL, following the existing pattern in raid5_change_consistency_policy().
Modified: 2026-03-25
CVE-2025-71136
In the Linux kernel, the following vulnerability has been resolved: media: adv7842: Avoid possible out-of-bounds array accesses in adv7842_cp_log_status() It's possible for cp_read() and hdmi_read() to return -EIO. Those values are further used as indexes for accessing arrays. Fix that by checking return values where it's needed. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/60dde0960e3ead8a9569f6c494d90d0232ac0983
- https://git.kernel.org/stable/c/8163419e3e05d71dcfa8fb49c8fdf8d76908fe51
- https://git.kernel.org/stable/c/a73881ae085db5702d8b13e2fc9f78d51c723d3f
- https://git.kernel.org/stable/c/b693d48a6ed0cd09171103ad418e4a693203d6e4
- https://git.kernel.org/stable/c/d6a22a4a96e4dfe6897cb3532d2b3016d87706f0
- https://git.kernel.org/stable/c/f81ee181cb036d046340c213091b69d9a8701a76
- https://git.kernel.org/stable/c/f913b9a2ccd6114b206b9e91dae5e3dc13a415a0
Modified: 2026-03-25
CVE-2025-71137
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix "UBSAN: shift-out-of-bounds error" This patch ensures that the RX ring size (rx_pending) is not set below the permitted length. This avoids UBSAN shift-out-of-bounds errors when users passes small or zero ring sizes via ethtool -G.
- https://git.kernel.org/stable/c/442848e457f5a9f71a4e7e14d24d73dae278ebe3
- https://git.kernel.org/stable/c/4cc4cfe4d23c883120b6f3d41145edbaa281f2ab
- https://git.kernel.org/stable/c/5d8dfa3abb9a845302e021cf9c92d941abbc011a
- https://git.kernel.org/stable/c/658caf3b8aad65f8b8e102670ca4f68c7030f655
- https://git.kernel.org/stable/c/85f4b0c650d9f9db10bda8d3acfa1af83bf78cf7
- https://git.kernel.org/stable/c/aa743b0d98448282b2cb37356db8db2a48524624
- https://git.kernel.org/stable/c/b23a2e15589466a027c9baa3fb5813c9f6a6c6dc
Modified: 2026-03-25
CVE-2025-71138
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: Add missing NULL pointer check for pingpong interface It is checked almost always in dpu_encoder_phys_wb_setup_ctl(), but in a single place the check is missing. Also use convenient locals instead of phys_enc->* where available. Patchwork: https://patchwork.freedesktop.org/patch/693860/
Modified: 2026-03-25
CVE-2025-71143
In the Linux kernel, the following vulnerability has been resolved: clk: samsung: exynos-clkout: Assign .num before accessing .hws Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS) about the number of elements in .hws[], so that it can warn when .hws[] is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in exynos_clkout_probe() due to .num being assigned after .hws[] has been accessed: UBSAN: array-index-out-of-bounds in drivers/clk/samsung/clk-exynos-clkout.c:178:18 index 0 is out of range for type 'clk_hw *[*]' Move the .num initialization to before the first access of .hws[], clearing up the warning.
Modified: 2026-02-26
CVE-2025-71146
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: fix leaked ct in error paths There are some situations where ct might be leaked as error paths are skipping the refcounted check and return immediately. In order to solve it make sure that the check is always called.
- https://git.kernel.org/stable/c/08fa37f4c8c59c294e9c18fea2d083ee94074e5a
- https://git.kernel.org/stable/c/0b88be7211d21a0d68bb1e56dc805944e3654d6f
- https://git.kernel.org/stable/c/2e2a720766886190a6d35c116794693aabd332b6
- https://git.kernel.org/stable/c/325eb61bb30790ea27782203a17b007ce1754a67
- https://git.kernel.org/stable/c/4bd2b89f4028f250dd1c1625eb3da1979b04a5e8
- https://git.kernel.org/stable/c/e1ac8dce3a893641bef224ad057932f142b8a36f
- https://git.kernel.org/stable/c/f381a33f34dda9e4023e38ba68c943bca83245e9
Modified: 2026-02-26
CVE-2025-71147
In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix a memory leak in tpm2_load_cmd 'tpm2_load_cmd' allocates a tempoary blob indirectly via 'tpm2_key_decode' but it is not freed in the failure paths. Address this by wrapping the blob into with a cleanup helper.
- https://git.kernel.org/stable/c/19166de9737218b77122c41a5730ac87025e089f
- https://git.kernel.org/stable/c/3fd7df4636d8fd5e3592371967a5941204368936
- https://git.kernel.org/stable/c/62cd5d480b9762ce70d720a81fa5b373052ae05f
- https://git.kernel.org/stable/c/9b015f2918b95bdde2ca9cefa10ef02b138aae1e
- https://git.kernel.org/stable/c/9e7c63c69f57b1db1a8a1542359a6167ff8fcef1
- https://git.kernel.org/stable/c/af0689cafb127a8d1af78cc8b72585c9b2a19ecd
Modified: 2026-02-26
CVE-2025-71148
In the Linux kernel, the following vulnerability has been resolved: net/handshake: restore destructor on submit failure handshake_req_submit() replaces sk->sk_destruct but never restores it when submission fails before the request is hashed. handshake_sk_destruct() then returns early and the original destructor never runs, leaking the socket. Restore sk_destruct on the error path.
Modified: 2026-04-18
CVE-2025-71150
In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix refcount leak when invalid session is found on session lookup When a session is found but its state is not SMB2_SESSION_VALID, It indicates that no valid session was found, but it is missing to decrement the reference count acquired by the session lookup, which results in a reference count leak. This patch fixes the issue by explicitly calling ksmbd_user_session_put to release the reference to the session.
- https://git.kernel.org/stable/c/02e06785e85b4bd86ef3d23b7c8d87acc76773d5
- https://git.kernel.org/stable/c/0fb87b28cafae71e9c8248432cc3a6a1fd759efc
- https://git.kernel.org/stable/c/11fe566b442e3bc2774191740fd377739a87a1c0
- https://git.kernel.org/stable/c/8cabcb4dd3dc85dd83a37d26efcc59a66a4074d7
- https://git.kernel.org/stable/c/cafb57f7bdd57abba87725eb4e82bbdca4959644
- https://git.kernel.org/stable/c/e54fb2a4772545701766cba08aab20de5eace8cd
Modified: 2026-02-26
CVE-2025-71151
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix memory and information leak in smb3_reconfigure() In smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the function returns immediately without freeing and erasing the newly allocated new_password and new_password2. This causes both a memory leak and a potential information leak. Fix this by calling kfree_sensitive() on both password buffers before returning in this error case.
Modified: 2026-02-26
CVE-2025-71153
In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix memory leak in get_file_all_info() In get_file_all_info(), if vfs_getattr() fails, the function returns immediately without freeing the allocated filename, leading to a memory leak. Fix this by freeing the filename before returning in this error case.
Modified: 2026-02-26
CVE-2025-71154
In the Linux kernel, the following vulnerability has been resolved: net: usb: rtl8150: fix memory leak on usb_submit_urb() failure In async_set_registers(), when usb_submit_urb() fails, the allocated async_req structure and URB are not freed, causing a memory leak. The completion callback async_set_reg_cb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked. Fix this by freeing both the URB and the request structure in the error path when usb_submit_urb() fails.
- https://git.kernel.org/stable/c/12cab1191d9890097171156d06bfa8d31f1e39c8
- https://git.kernel.org/stable/c/151403e903840c9cf06754097b6732c14f26c532
- https://git.kernel.org/stable/c/2f966186b99550e3c665dbfb87b8314e30acea02
- https://git.kernel.org/stable/c/4bd4ea3eb326608ffc296db12c105f92dc2f2190
- https://git.kernel.org/stable/c/6492ad6439ff1a479fc94dc6052df3628faed8b6
- https://git.kernel.org/stable/c/a4e2442d3c48355a84463342f397134f149936d7
- https://git.kernel.org/stable/c/db2244c580540306d60ce783ed340190720cd429
Modified: 2026-02-26
CVE-2025-71156
In the Linux kernel, the following vulnerability has been resolved:
gve: defer interrupt enabling until NAPI registration
Currently, interrupts are automatically enabled immediately upon
request. This allows interrupt to fire before the associated NAPI
context is fully initialized and cause failures like below:
[ 0.946369] Call Trace:
[ 0.946369]
Modified: 2026-02-26
CVE-2025-71157
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: always drop device refcount in ib_del_sub_device_and_put() Since nldev_deldev() (introduced by commit 060c642b2ab8 ("RDMA/nldev: Add support to add/delete a sub IB device through netlink") grabs a reference using ib_device_get_by_index() before calling ib_del_sub_device_and_put(), we need to drop that reference before returning -EOPNOTSUPP error.
