Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Vulnerabilidades

Con el objetivo de informar, advertir y ayudar a los profesionales sobre las ultimas vulnerabilidades de seguridad en sistemas tecnológicos, ponemos a disposición de los usuarios interesados en esta información una base de datos con información en castellano sobre cada una de las ultimas vulnerabilidades documentadas y conocidas.

Este repositorio con más de 75.000 registros esta basado en la información de NVD (National Vulnerability Database) – en función de un acuerdo de colaboración – por el cual desde INCIBE realizamos la traducción al castellano de la información incluida. En ocasiones este listado mostrará vulnerabilidades que aún no han sido traducidas debido a que se recogen en el transcurso del tiempo en el que el equipo de INCIBE realiza el proceso de traducción.

Se emplea el estándar de nomenclatura de vulnerabilidades CVE (Common Vulnerabilities and Exposures), con el fin de facilitar el intercambio de información entre diferentes bases de datos y herramientas. Cada una de las vulnerabilidades recogidas enlaza a diversas fuentes de información así como a parches disponibles o soluciones aportadas por los fabricantes y desarrolladores. Es posible realizar búsquedas avanzadas teniendo la opción de seleccionar diferentes criterios como el tipo de vulnerabilidad, fabricante, tipo de impacto entre otros, con el fin de acortar los resultados.

Mediante suscripción RSS o Boletines podemos estar informados diariamente de las ultimas vulnerabilidades incorporadas al repositorio.

CVE-2026-23035

Fecha de publicación:
31/01/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv<br /> <br /> mlx5e_priv is an unstable structure that can be memset(0) if profile<br /> attaching fails.<br /> <br /> Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on a<br /> valid netdev.<br /> <br /> On mlx5e_remove: Check validity of priv-&gt;profile, before attempting<br /> to cleanup any resources that might be not there.<br /> <br /> This fixes a kernel oops in mlx5e_remove when switchdev mode fails due<br /> to change profile failure.<br /> <br /> $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev<br /> Error: mlx5_core: Failed setting eswitch to offloads.<br /> dmesg:<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12<br /> <br /> $ devlink dev reload pci/0000:00:03.0 ==&gt; oops<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000370<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100<br /> RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286<br /> RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0<br /> RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10<br /> R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0<br /> R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400<br /> FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0<br /> Call Trace:<br /> <br /> mlx5e_remove+0x57/0x110<br /> device_release_driver_internal+0x19c/0x200<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x160/0x3d0<br /> ? devl_param_driverinit_value_get+0x2d/0x90<br /> mlx5_detach_device+0x89/0xe0<br /> mlx5_unload_one_devl_locked+0x3a/0x70<br /> mlx5_devlink_reload_down+0xc8/0x220<br /> devlink_reload+0x7d/0x260<br /> devlink_nl_reload_doit+0x45b/0x5a0<br /> genl_family_rcv_msg_doit+0xe8/0x140
Gravedad: Pendiente de análisis
Última modificación:
31/01/2026

CVE-2026-23036

Fecha de publicación:
31/01/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release path before iget_failed() in btrfs_read_locked_inode()<br /> <br /> In btrfs_read_locked_inode() if we fail to lookup the inode, we jump to<br /> the &amp;#39;out&amp;#39; label with a path that has a read locked leaf and then we call<br /> iget_failed(). This can result in a ABBA deadlock, since iget_failed()<br /> triggers inode eviction and that causes the release of the delayed inode,<br /> which must lock the delayed inode&amp;#39;s mutex, and a task updating a delayed<br /> inode starts by taking the node&amp;#39;s mutex and then modifying the inode&amp;#39;s<br /> subvolume btree.<br /> <br /> Syzbot reported the following lockdep splat for this:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> syzkaller #0 Not tainted<br /> ------------------------------------------------------<br /> btrfs-cleaner/8725 is trying to acquire lock:<br /> ffff0000d6826a48 (&amp;delayed_node-&gt;mutex){+.+.}-{4:4}, at: __btrfs_release_delayed_node+0xa0/0x9b0 fs/btrfs/delayed-inode.c:290<br /> <br /> but task is already holding lock:<br /> ffff0000dbeba878 (btrfs-tree-00){++++}-{4:4}, at: btrfs_tree_read_lock_nested+0x44/0x2ec fs/btrfs/locking.c:145<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (btrfs-tree-00){++++}-{4:4}:<br /> __lock_release kernel/locking/lockdep.c:5574 [inline]<br /> lock_release+0x198/0x39c kernel/locking/lockdep.c:5889<br /> up_read+0x24/0x3c kernel/locking/rwsem.c:1632<br /> btrfs_tree_read_unlock+0xdc/0x298 fs/btrfs/locking.c:169<br /> btrfs_tree_unlock_rw fs/btrfs/locking.h:218 [inline]<br /> btrfs_search_slot+0xa6c/0x223c fs/btrfs/ctree.c:2133<br /> btrfs_lookup_inode+0xd8/0x38c fs/btrfs/inode-item.c:395<br /> __btrfs_update_delayed_inode+0x124/0xed0 fs/btrfs/delayed-inode.c:1032<br /> btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1118 [inline]<br /> __btrfs_commit_inode_delayed_items+0x15f8/0x1748 fs/btrfs/delayed-inode.c:1141<br /> __btrfs_run_delayed_items+0x1ac/0x514 fs/btrfs/delayed-inode.c:1176<br /> btrfs_run_delayed_items_nr+0x28/0x38 fs/btrfs/delayed-inode.c:1219<br /> flush_space+0x26c/0xb68 fs/btrfs/space-info.c:828<br /> do_async_reclaim_metadata_space+0x110/0x364 fs/btrfs/space-info.c:1158<br /> btrfs_async_reclaim_metadata_space+0x90/0xd8 fs/btrfs/space-info.c:1226<br /> process_one_work+0x7e8/0x155c kernel/workqueue.c:3263<br /> process_scheduled_works kernel/workqueue.c:3346 [inline]<br /> worker_thread+0x958/0xed8 kernel/workqueue.c:3427<br /> kthread+0x5fc/0x75c kernel/kthread.c:463<br /> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:844<br /> <br /> -&gt; #0 (&amp;delayed_node-&gt;mutex){+.+.}-{4:4}:<br /> check_prev_add kernel/locking/lockdep.c:3165 [inline]<br /> check_prevs_add kernel/locking/lockdep.c:3284 [inline]<br /> validate_chain kernel/locking/lockdep.c:3908 [inline]<br /> __lock_acquire+0x1774/0x30a4 kernel/locking/lockdep.c:5237<br /> lock_acquire+0x14c/0x2e0 kernel/locking/lockdep.c:5868<br /> __mutex_lock_common+0x1d0/0x2678 kernel/locking/mutex.c:598<br /> __mutex_lock kernel/locking/mutex.c:760 [inline]<br /> mutex_lock_nested+0x2c/0x38 kernel/locking/mutex.c:812<br /> __btrfs_release_delayed_node+0xa0/0x9b0 fs/btrfs/delayed-inode.c:290<br /> btrfs_release_delayed_node fs/btrfs/delayed-inode.c:315 [inline]<br /> btrfs_remove_delayed_node+0x68/0x84 fs/btrfs/delayed-inode.c:1326<br /> btrfs_evict_inode+0x578/0xe28 fs/btrfs/inode.c:5587<br /> evict+0x414/0x928 fs/inode.c:810<br /> iput_final fs/inode.c:1914 [inline]<br /> iput+0x95c/0xad4 fs/inode.c:1966<br /> iget_failed+0xec/0x134 fs/bad_inode.c:248<br /> btrfs_read_locked_inode+0xe1c/0x1234 fs/btrfs/inode.c:4101<br /> btrfs_iget+0x1b0/0x264 fs/btrfs/inode.c:5837<br /> btrfs_run_defrag_inode fs/btrfs/defrag.c:237 [inline]<br /> btrfs_run_defrag_inodes+0x520/0xdc4 fs/btrf<br /> ---truncated---
Gravedad: Pendiente de análisis
Última modificación:
31/01/2026

CVE-2026-23017

Fecha de publicación:
31/01/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix error handling in the init_task on load<br /> <br /> If the init_task fails during a driver load, we end up without vports and<br /> netdevs, effectively failing the entire process. In that state a<br /> subsequent reset will result in a crash as the service task attempts to<br /> access uninitialized resources. Following trace is from an error in the<br /> init_task where the CREATE_VPORT (op 501) is rejected by the FW:<br /> <br /> [40922.763136] idpf 0000:83:00.0: Device HW Reset initiated<br /> [40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)<br /> [40958.148190] idpf 0000:83:00.0: HW reset detected<br /> [40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8<br /> ...<br /> [40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf]<br /> [40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]<br /> ...<br /> [40958.177932] Call Trace:<br /> [40958.178491] <br /> [40958.179040] process_one_work+0x226/0x6d0<br /> [40958.179609] worker_thread+0x19e/0x340<br /> [40958.180158] ? __pfx_worker_thread+0x10/0x10<br /> [40958.180702] kthread+0x10f/0x250<br /> [40958.181238] ? __pfx_kthread+0x10/0x10<br /> [40958.181774] ret_from_fork+0x251/0x2b0<br /> [40958.182307] ? __pfx_kthread+0x10/0x10<br /> [40958.182834] ret_from_fork_asm+0x1a/0x30<br /> [40958.183370] <br /> <br /> Fix the error handling in the init_task to make sure the service and<br /> mailbox tasks are disabled if the error happens during load. These are<br /> started in idpf_vc_core_init(), which spawns the init_task and has no way<br /> of knowing if it failed. If the error happens on reset, following<br /> successful driver load, the tasks can still run, as that will allow the<br /> netdevs to attempt recovery through another reset. Stop the PTP callbacks<br /> either way as those will be restarted by the call to idpf_vc_core_init()<br /> during a successful reset.
Gravedad: Pendiente de análisis
Última modificación:
31/01/2026

CVE-2026-23018

Fecha de publicación:
31/01/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release path before initializing extent tree in btrfs_read_locked_inode()<br /> <br /> In btrfs_read_locked_inode() we are calling btrfs_init_file_extent_tree()<br /> while holding a path with a read locked leaf from a subvolume tree, and<br /> btrfs_init_file_extent_tree() may do a GFP_KERNEL allocation, which can<br /> trigger reclaim.<br /> <br /> This can create a circular lock dependency which lockdep warns about with<br /> the following splat:<br /> <br /> [6.1433] ======================================================<br /> [6.1574] WARNING: possible circular locking dependency detected<br /> [6.1583] 6.18.0+ #4 Tainted: G U<br /> [6.1591] ------------------------------------------------------<br /> [6.1599] kswapd0/117 is trying to acquire lock:<br /> [6.1606] ffff8d9b6333c5b8 (&amp;delayed_node-&gt;mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x39/0x2f0<br /> [6.1625]<br /> but task is already holding lock:<br /> [6.1633] ffffffffa4ab8ce0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x195/0xc60<br /> [6.1646]<br /> which lock already depends on the new lock.<br /> <br /> [6.1657]<br /> the existing dependency chain (in reverse order) is:<br /> [6.1667]<br /> -&gt; #2 (fs_reclaim){+.+.}-{0:0}:<br /> [6.1677] fs_reclaim_acquire+0x9d/0xd0<br /> [6.1685] __kmalloc_cache_noprof+0x59/0x750<br /> [6.1694] btrfs_init_file_extent_tree+0x90/0x100<br /> [6.1702] btrfs_read_locked_inode+0xc3/0x6b0<br /> [6.1710] btrfs_iget+0xbb/0xf0<br /> [6.1716] btrfs_lookup_dentry+0x3c5/0x8e0<br /> [6.1724] btrfs_lookup+0x12/0x30<br /> [6.1731] lookup_open.isra.0+0x1aa/0x6a0<br /> [6.1739] path_openat+0x5f7/0xc60<br /> [6.1746] do_filp_open+0xd6/0x180<br /> [6.1753] do_sys_openat2+0x8b/0xe0<br /> [6.1760] __x64_sys_openat+0x54/0xa0<br /> [6.1768] do_syscall_64+0x97/0x3e0<br /> [6.1776] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [6.1784]<br /> -&gt; #1 (btrfs-tree-00){++++}-{3:3}:<br /> [6.1794] lock_release+0x127/0x2a0<br /> [6.1801] up_read+0x1b/0x30<br /> [6.1808] btrfs_search_slot+0x8e0/0xff0<br /> [6.1817] btrfs_lookup_inode+0x52/0xd0<br /> [6.1825] __btrfs_update_delayed_inode+0x73/0x520<br /> [6.1833] btrfs_commit_inode_delayed_inode+0x11a/0x120<br /> [6.1842] btrfs_log_inode+0x608/0x1aa0<br /> [6.1849] btrfs_log_inode_parent+0x249/0xf80<br /> [6.1857] btrfs_log_dentry_safe+0x3e/0x60<br /> [6.1865] btrfs_sync_file+0x431/0x690<br /> [6.1872] do_fsync+0x39/0x80<br /> [6.1879] __x64_sys_fsync+0x13/0x20<br /> [6.1887] do_syscall_64+0x97/0x3e0<br /> [6.1894] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [6.1903]<br /> -&gt; #0 (&amp;delayed_node-&gt;mutex){+.+.}-{3:3}:<br /> [6.1913] __lock_acquire+0x15e9/0x2820<br /> [6.1920] lock_acquire+0xc9/0x2d0<br /> [6.1927] __mutex_lock+0xcc/0x10a0<br /> [6.1934] __btrfs_release_delayed_node.part.0+0x39/0x2f0<br /> [6.1944] btrfs_evict_inode+0x20b/0x4b0<br /> [6.1952] evict+0x15a/0x2f0<br /> [6.1958] prune_icache_sb+0x91/0xd0<br /> [6.1966] super_cache_scan+0x150/0x1d0<br /> [6.1974] do_shrink_slab+0x155/0x6f0<br /> [6.1981] shrink_slab+0x48e/0x890<br /> [6.1988] shrink_one+0x11a/0x1f0<br /> [6.1995] shrink_node+0xbfd/0x1320<br /> [6.1002] balance_pgdat+0x67f/0xc60<br /> [6.1321] kswapd+0x1dc/0x3e0<br /> [6.1643] kthread+0xff/0x240<br /> [6.1965] ret_from_fork+0x223/0x280<br /> [6.1287] ret_from_fork_asm+0x1a/0x30<br /> [6.1616]<br /> other info that might help us debug this:<br /> <br /> [6.1561] Chain exists of:<br /> &amp;delayed_node-&gt;mutex --&gt; btrfs-tree-00 --&gt; fs_reclaim<br /> <br /> [6.1503] Possible unsafe locking scenario:<br /> <br /> [6.1110] CPU0 CPU1<br /> [6.1411] ---- ----<br /> [6.1707] lock(fs_reclaim);<br /> [6.1998] lock(btrfs-tree-00);<br /> [6.1291] lock(fs_reclaim);<br /> [6.1581] lock(&amp;del<br /> ---truncated---
Gravedad: Pendiente de análisis
Última modificación:
31/01/2026

CVE-2026-23019

Fecha de publicación:
31/01/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: marvell: prestera: fix NULL dereference on devlink_alloc() failure<br /> <br /> devlink_alloc() may return NULL on allocation failure, but<br /> prestera_devlink_alloc() unconditionally calls devlink_priv() on<br /> the returned pointer.<br /> <br /> This leads to a NULL pointer dereference if devlink allocation fails.<br /> Add a check for a NULL devlink pointer and return NULL early to avoid<br /> the crash.
Gravedad: Pendiente de análisis
Última modificación:
31/01/2026

CVE-2026-23020

Fecha de publicación:
31/01/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: 3com: 3c59x: fix possible null dereference in vortex_probe1()<br /> <br /> pdev can be null and free_ring: can be called in 1297 with a null<br /> pdev.
Gravedad: Pendiente de análisis
Última modificación:
31/01/2026

CVE-2026-23021

Fecha de publicación:
31/01/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: pegasus: fix memory leak in update_eth_regs_async()<br /> <br /> When asynchronously writing to the device registers and if usb_submit_urb()<br /> fail, the code fail to release allocated to this point resources.
Gravedad: Pendiente de análisis
Última modificación:
31/01/2026

CVE-2026-23022

Fecha de publicación:
31/01/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix memory leak in idpf_vc_core_deinit()<br /> <br /> Make sure to free hw-&gt;lan_regs. Reported by kmemleak during reset:<br /> <br /> unreferenced object 0xff1b913d02a936c0 (size 96):<br /> comm "kworker/u258:14", pid 2174, jiffies 4294958305<br /> hex dump (first 32 bytes):<br /> 00 00 00 c0 a8 ba 2d ff 00 00 00 00 00 00 00 00 ......-.........<br /> 00 00 40 08 00 00 00 00 00 00 25 b3 a8 ba 2d ff ..@.......%...-.<br /> backtrace (crc 36063c4f):<br /> __kmalloc_noprof+0x48f/0x890<br /> idpf_vc_core_init+0x6ce/0x9b0 [idpf]<br /> idpf_vc_event_task+0x1fb/0x350 [idpf]<br /> process_one_work+0x226/0x6d0<br /> worker_thread+0x19e/0x340<br /> kthread+0x10f/0x250<br /> ret_from_fork+0x251/0x2b0<br /> ret_from_fork_asm+0x1a/0x30
Gravedad: Pendiente de análisis
Última modificación:
31/01/2026

CVE-2026-23023

Fecha de publicación:
31/01/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix memory leak in idpf_vport_rel()<br /> <br /> Free vport-&gt;rx_ptype_lkup in idpf_vport_rel() to avoid leaking memory<br /> during a reset. Reported by kmemleak:<br /> <br /> unreferenced object 0xff450acac838a000 (size 4096):<br /> comm "kworker/u258:5", pid 7732, jiffies 4296830044<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 10 00 00 00 10 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 ................<br /> backtrace (crc 3da81902):<br /> __kmalloc_cache_noprof+0x469/0x7a0<br /> idpf_send_get_rx_ptype_msg+0x90/0x570 [idpf]<br /> idpf_init_task+0x1ec/0x8d0 [idpf]<br /> process_one_work+0x226/0x6d0<br /> worker_thread+0x19e/0x340<br /> kthread+0x10f/0x250<br /> ret_from_fork+0x251/0x2b0<br /> ret_from_fork_asm+0x1a/0x30
Gravedad: Pendiente de análisis
Última modificación:
31/01/2026

CVE-2026-23024

Fecha de publicación:
31/01/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix memory leak of flow steer list on rmmod<br /> <br /> The flow steering list maintains entries that are added and removed as<br /> ethtool creates and deletes flow steering rules. Module removal with active<br /> entries causes memory leak as the list is not properly cleaned up.<br /> <br /> Prevent this by iterating through the remaining entries in the list and<br /> freeing the associated memory during module removal. Add a spinlock<br /> (flow_steer_list_lock) to protect the list access from multiple threads.
Gravedad: Pendiente de análisis
Última modificación:
31/01/2026

CVE-2026-23025

Fecha de publicación:
31/01/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_alloc: prevent pcp corruption with SMP=n<br /> <br /> The kernel test robot has reported:<br /> <br /> BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28<br /> lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0<br /> CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470<br /> Call Trace:<br /> <br /> __dump_stack (lib/dump_stack.c:95)<br /> dump_stack_lvl (lib/dump_stack.c:123)<br /> dump_stack (lib/dump_stack.c:130)<br /> spin_dump (kernel/locking/spinlock_debug.c:71)<br /> do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?)<br /> _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138)<br /> __free_frozen_pages (mm/page_alloc.c:2973)<br /> ___free_pages (mm/page_alloc.c:5295)<br /> __free_pages (mm/page_alloc.c:5334)<br /> tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290)<br /> ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289)<br /> ? rcu_core (kernel/rcu/tree.c:?)<br /> rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861)<br /> rcu_core_si (kernel/rcu/tree.c:2879)<br /> handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623)<br /> __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725)<br /> irq_exit_rcu (kernel/softirq.c:741)<br /> sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052)<br /> <br /> <br /> RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194)<br /> free_pcppages_bulk (mm/page_alloc.c:1494)<br /> drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632)<br /> __drain_all_pages (mm/page_alloc.c:2731)<br /> drain_all_pages (mm/page_alloc.c:2747)<br /> kcompactd (mm/compaction.c:3115)<br /> kthread (kernel/kthread.c:465)<br /> ? __cfi_kcompactd (mm/compaction.c:3166)<br /> ? __cfi_kthread (kernel/kthread.c:412)<br /> ret_from_fork (arch/x86/kernel/process.c:164)<br /> ? __cfi_kthread (kernel/kthread.c:412)<br /> ret_from_fork_asm (arch/x86/entry/entry_64.S:255)<br /> <br /> <br /> Matthew has analyzed the report and identified that in drain_page_zone()<br /> we are in a section protected by spin_lock(&amp;pcp-&gt;lock) and then get an<br /> interrupt that attempts spin_trylock() on the same lock. The code is<br /> designed to work this way without disabling IRQs and occasionally fail the<br /> trylock with a fallback. However, the SMP=n spinlock implementation<br /> assumes spin_trylock() will always succeed, and thus it&amp;#39;s normally a<br /> no-op. Here the enabled lock debugging catches the problem, but otherwise<br /> it could cause a corruption of the pcp structure.<br /> <br /> The problem has been introduced by commit 574907741599 ("mm/page_alloc:<br /> leave IRQs enabled for per-cpu page allocations"). The pcp locking scheme<br /> recognizes the need for disabling IRQs to prevent nesting spin_trylock()<br /> sections on SMP=n, but the need to prevent the nesting in spin_lock() has<br /> not been recognized. Fix it by introducing local wrappers that change the<br /> spin_lock() to spin_lock_iqsave() with SMP=n and use them in all places<br /> that do spin_lock(&amp;pcp-&gt;lock).<br /> <br /> [vbabka@suse.cz: add pcp_ prefix to the spin_lock_irqsave wrappers, per Steven]
Gravedad: Pendiente de análisis
Última modificación:
31/01/2026

CVE-2026-23026

Fecha de publicación:
31/01/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()<br /> <br /> Fix a memory leak in gpi_peripheral_config() where the original memory<br /> pointed to by gchan-&gt;config could be lost if krealloc() fails.<br /> <br /> The issue occurs when:<br /> 1. gchan-&gt;config points to previously allocated memory<br /> 2. krealloc() fails and returns NULL<br /> 3. The function directly assigns NULL to gchan-&gt;config, losing the<br /> reference to the original memory<br /> 4. The original memory becomes unreachable and cannot be freed<br /> <br /> Fix this by using a temporary variable to hold the krealloc() result<br /> and only updating gchan-&gt;config when the allocation succeeds.<br /> <br /> Found via static analysis and code review.
Gravedad: Pendiente de análisis
Última modificación:
31/01/2026