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-2025-40238

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix IPsec cleanup over MPV device<br /> <br /> When we do mlx5e_detach_netdev() we eventually disable blocking events<br /> notifier, among those events are IPsec MPV events from IB to core.<br /> <br /> So before disabling those blocking events, make sure to also unregister<br /> the devcom device and mark all this device operations as complete,<br /> in order to prevent the other device from using invalid netdev<br /> during future devcom events which could cause the trace below.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> PGD 146427067 P4D 146427067 PUD 146488067 PMD 0<br /> Oops: Oops: 0000 [#1] SMP<br /> CPU: 1 UID: 0 PID: 7735 Comm: devlink Tainted: GW 6.12.0-rc6_for_upstream_min_debug_2024_11_08_00_46 #1<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core]<br /> Code: 00 01 48 83 05 23 32 1e 00 01 41 b8 ed ff ff ff e9 60 ff ff ff 48 83 05 00 32 1e 00 01 eb e3 66 0f 1f 44 00 00 0f 1f 44 00 00 8b 47 10 48 83 05 5f 32 1e 00 01 48 8b 50 40 48 85 d2 74 05 40<br /> RSP: 0018:ffff88811a5c35f8 EFLAGS: 00010206<br /> RAX: ffff888106e8ab80 RBX: ffff888107d7e200 RCX: ffff88810d6f0a00<br /> RDX: ffff88810d6f0a00 RSI: 0000000000000001 RDI: 0000000000000000<br /> RBP: ffff88811a17e620 R08: 0000000000000040 R09: 0000000000000000<br /> R10: ffff88811a5c3618 R11: 0000000de85d51bd R12: ffff88811a17e600<br /> R13: ffff88810d6f0a00 R14: 0000000000000000 R15: ffff8881034bda80<br /> FS: 00007f27bdf89180(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000010 CR3: 000000010f159005 CR4: 0000000000372eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __die+0x20/0x60<br /> ? page_fault_oops+0x150/0x3e0<br /> ? exc_page_fault+0x74/0x130<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core]<br /> mlx5e_devcom_event_mpv+0x42/0x60 [mlx5_core]<br /> mlx5_devcom_send_event+0x8c/0x170 [mlx5_core]<br /> blocking_event+0x17b/0x230 [mlx5_core]<br /> notifier_call_chain+0x35/0xa0<br /> blocking_notifier_call_chain+0x3d/0x60<br /> mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]<br /> mlx5_core_mp_event_replay+0x12/0x20 [mlx5_core]<br /> mlx5_ib_bind_slave_port+0x228/0x2c0 [mlx5_ib]<br /> mlx5_ib_stage_init_init+0x664/0x9d0 [mlx5_ib]<br /> ? idr_alloc_cyclic+0x50/0xb0<br /> ? __kmalloc_cache_noprof+0x167/0x340<br /> ? __kmalloc_noprof+0x1a7/0x430<br /> __mlx5_ib_add+0x34/0xd0 [mlx5_ib]<br /> mlx5r_probe+0xe9/0x310 [mlx5_ib]<br /> ? kernfs_add_one+0x107/0x150<br /> ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib]<br /> auxiliary_bus_probe+0x3e/0x90<br /> really_probe+0xc5/0x3a0<br /> ? driver_probe_device+0x90/0x90<br /> __driver_probe_device+0x80/0x160<br /> driver_probe_device+0x1e/0x90<br /> __device_attach_driver+0x7d/0x100<br /> bus_for_each_drv+0x80/0xd0<br /> __device_attach+0xbc/0x1f0<br /> bus_probe_device+0x86/0xa0<br /> device_add+0x62d/0x830<br /> __auxiliary_device_add+0x3b/0xa0<br /> ? auxiliary_device_init+0x41/0x90<br /> add_adev+0xd1/0x150 [mlx5_core]<br /> mlx5_rescan_drivers_locked+0x21c/0x300 [mlx5_core]<br /> esw_mode_change+0x6c/0xc0 [mlx5_core]<br /> mlx5_devlink_eswitch_mode_set+0x21e/0x640 [mlx5_core]<br /> devlink_nl_eswitch_set_doit+0x60/0xe0<br /> genl_family_rcv_msg_doit+0xd0/0x120<br /> genl_rcv_msg+0x180/0x2b0<br /> ? devlink_get_from_attrs_lock+0x170/0x170<br /> ? devlink_nl_eswitch_get_doit+0x290/0x290<br /> ? devlink_nl_pre_doit_port_optional+0x50/0x50<br /> ? genl_family_rcv_msg_dumpit+0xf0/0xf0<br /> netlink_rcv_skb+0x54/0x100<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x1fc/0x2d0<br /> netlink_sendmsg+0x1e4/0x410<br /> __sock_sendmsg+0x38/0x60<br /> ? sockfd_lookup_light+0x12/0x60<br /> __sys_sendto+0x105/0x160<br /> ? __sys_recvmsg+0x4e/0x90<br /> __x64_sys_sendto+0x20/0x30<br /> do_syscall_64+0x4c/0x100<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f27bc91b13a<br /> Code: bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 8b 05 fa 96 2c 00 45 89 c9 4c 63 d1 48 63 ff 85 c0 75 15 b8 2c 00 00 00 0f 05 3d 00 f0 ff ff <br /> ---truncated---
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40239

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: micrel: always set shared-&gt;phydev for LAN8814<br /> <br /> Currently, during the LAN8814 PTP probe shared-&gt;phydev is only set if PTP<br /> clock gets actually set, otherwise the function will return before setting<br /> it.<br /> <br /> This is an issue as shared-&gt;phydev is unconditionally being used when IRQ<br /> is being handled, especially in lan8814_gpio_process_cap and since it was<br /> not set it will cause a NULL pointer exception and crash the kernel.<br /> <br /> So, simply always set shared-&gt;phydev to avoid the NULL pointer exception.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40225

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Fix kernel panic on partial unmap of a GPU VA region<br /> <br /> This commit address a kernel panic issue that can happen if Userspace<br /> tries to partially unmap a GPU virtual region (aka drm_gpuva).<br /> The VM_BIND interface allows partial unmapping of a BO.<br /> <br /> Panthor driver pre-allocates memory for the new drm_gpuva structures<br /> that would be needed for the map/unmap operation, done using drm_gpuvm<br /> layer. It expected that only one new drm_gpuva would be needed on umap<br /> but a partial unmap can require 2 new drm_gpuva and that&amp;#39;s why it<br /> ended up doing a NULL pointer dereference causing a kernel panic.<br /> <br /> Following dump was seen when partial unmap was exercised.<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000078<br /> Mem abort info:<br /> ESR = 0x0000000096000046<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x06: level 2 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000<br /> CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000088a863000<br /> [000000000000078] pgd=080000088a842003, p4d=080000088a842003, pud=0800000884bf5003, pmd=0000000000000000<br /> Internal error: Oops: 0000000096000046 [#1] PREEMPT SMP<br /> <br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor]<br /> lr : panthor_gpuva_sm_step_remap+0x6c/0x330 [panthor]<br /> sp : ffff800085d43970<br /> x29: ffff800085d43970 x28: ffff00080363e440 x27: ffff0008090c6000<br /> x26: 0000000000000030 x25: ffff800085d439f8 x24: ffff00080d402000<br /> x23: ffff800085d43b60 x22: ffff800085d439e0 x21: ffff00080abdb180<br /> x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000010<br /> x17: 6e656c202c303030 x16: 3666666666646466 x15: 393d61766f69202c<br /> x14: 312d3d7361203a70 x13: 303030323d6e656c x12: ffff80008324bf58<br /> x11: 0000000000000003 x10: 0000000000000002 x9 : ffff8000801a6a9c<br /> x8 : ffff00080360b300 x7 : 0000000000000000 x6 : 000000088aa35fc7<br /> x5 : fff1000080000000 x4 : ffff8000842ddd30 x3 : 0000000000000001<br /> x2 : 0000000100000000 x1 : 0000000000000001 x0 : 0000000000000078<br /> Call trace:<br /> panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor]<br /> op_remap_cb.isra.22+0x50/0x80<br /> __drm_gpuvm_sm_unmap+0x10c/0x1c8<br /> drm_gpuvm_sm_unmap+0x40/0x60<br /> panthor_vm_exec_op+0xb4/0x3d0 [panthor]<br /> panthor_vm_bind_exec_sync_op+0x154/0x278 [panthor]<br /> panthor_ioctl_vm_bind+0x160/0x4a0 [panthor]<br /> drm_ioctl_kernel+0xbc/0x138<br /> drm_ioctl+0x240/0x500<br /> __arm64_sys_ioctl+0xb0/0xf8<br /> invoke_syscall+0x4c/0x110<br /> el0_svc_common.constprop.1+0x98/0xf8<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x40/0xf8<br /> el0t_64_sync_handler+0xa0/0xc8<br /> el0t_64_sync+0x174/0x178
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40226

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scmi: Account for failed debug initialization<br /> <br /> When the SCMI debug subsystem fails to initialize, the related debug root<br /> will be missing, and the underlying descriptor will be NULL.<br /> <br /> Handle this fault condition in the SCMI debug helpers that maintain<br /> metrics counters.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40227

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: dealloc commit test ctx always<br /> <br /> The damon_ctx for testing online DAMON parameters commit inputs is<br /> deallocated only when the test fails. This means memory is leaked for<br /> every successful online DAMON parameters commit. Fix the leak by always<br /> deallocating it.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40228

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: catch commit test ctx alloc failure<br /> <br /> Patch series "mm/damon/sysfs: fix commit test damon_ctx [de]allocation".<br /> <br /> DAMON sysfs interface dynamically allocates and uses a damon_ctx object<br /> for testing if given inputs for online DAMON parameters update is valid.<br /> The object is being used without an allocation failure check, and leaked<br /> when the test succeeds. Fix the two bugs.<br /> <br /> <br /> This patch (of 2):<br /> <br /> The damon_ctx for testing online DAMON parameters commit inputs is used<br /> without its allocation failure check. This could result in an invalid<br /> memory access. Fix it by directly returning an error when the allocation<br /> failed.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40229

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme<br /> <br /> Currently, damon_destroy_scheme() only cleans up the filter list but<br /> leaves ops_filter untouched, which could lead to memory leaks when a<br /> scheme is destroyed.<br /> <br /> This patch ensures both filter and ops_filter are properly freed in<br /> damon_destroy_scheme(), preventing potential memory leaks.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40230

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: prevent poison consumption when splitting THP<br /> <br /> When performing memory error injection on a THP (Transparent Huge Page)<br /> mapped to userspace on an x86 server, the kernel panics with the following<br /> trace. The expected behavior is to terminate the affected process instead<br /> of panicking the kernel, as the x86 Machine Check code can recover from an<br /> in-userspace #MC.<br /> <br /> mce: [Hardware Error]: CPU 0: Machine Check Exception: f Bank 3: bd80000000070134<br /> mce: [Hardware Error]: RIP 10: {memchr_inv+0x4c/0xf0}<br /> mce: [Hardware Error]: TSC afff7bbff88a ADDR 1d301b000 MISC 80 PPIN 1e741e77539027db<br /> mce: [Hardware Error]: PROCESSOR 0:d06d0 TIME 1758093249 SOCKET 0 APIC 0 microcode 80000320<br /> mce: [Hardware Error]: Run the above through &amp;#39;mcelog --ascii&amp;#39;<br /> mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel<br /> Kernel panic - not syncing: Fatal local machine check<br /> <br /> The root cause of this panic is that handling a memory failure triggered<br /> by an in-userspace #MC necessitates splitting the THP. The splitting<br /> process employs a mechanism, implemented in<br /> try_to_map_unused_to_zeropage(), which reads the pages in the THP to<br /> identify zero-filled pages. However, reading the pages in the THP results<br /> in a second in-kernel #MC, occurring before the initial memory_failure()<br /> completes, ultimately leading to a kernel panic. See the kernel panic<br /> call trace on the two #MCs.<br /> <br /> First Machine Check occurs // [1]<br /> memory_failure() // [2]<br /> try_to_split_thp_page()<br /> split_huge_page()<br /> split_huge_page_to_list_to_order()<br /> __folio_split() // [3]<br /> remap_page()<br /> remove_migration_ptes()<br /> remove_migration_pte()<br /> try_to_map_unused_to_zeropage() // [4]<br /> memchr_inv() // [5]<br /> Second Machine Check occurs // [6]<br /> Kernel panic<br /> <br /> [1] Triggered by accessing a hardware-poisoned THP in userspace, which is<br /> typically recoverable by terminating the affected process.<br /> <br /> [2] Call folio_set_has_hwpoisoned() before try_to_split_thp_page().<br /> <br /> [3] Pass the RMP_USE_SHARED_ZEROPAGE remap flag to remap_page().<br /> <br /> [4] Try to map the unused THP to zeropage.<br /> <br /> [5] Re-access pages in the hw-poisoned THP in the kernel.<br /> <br /> [6] Triggered in-kernel, leading to a panic kernel.<br /> <br /> In Step[2], memory_failure() sets the poisoned flag on the page in the THP<br /> by TestSetPageHWPoison() before calling try_to_split_thp_page().<br /> <br /> As suggested by David Hildenbrand, fix this panic by not accessing to the<br /> poisoned page in the THP during zeropage identification, while continuing<br /> to scan unaffected pages in the THP for possible zeropage mapping. This<br /> prevents a second in-kernel #MC that would cause kernel panic in Step[4].<br /> <br /> Thanks to Andrew Zaborowski for his initial work on fixing this issue.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40231

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: fix lock inversion in vsock_assign_transport()<br /> <br /> Syzbot reported a potential lock inversion deadlock between<br /> vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.<br /> <br /> The issue was introduced by commit 687aa0c5581b ("vsock: Fix<br /> transport_* TOCTOU") which added vsock_register_mutex locking in<br /> vsock_assign_transport() around the transport-&gt;release() call, that can<br /> call vsock_linger(). vsock_assign_transport() can be called with sk_lock<br /> held. vsock_linger() calls sk_wait_event() that temporarily releases and<br /> re-acquires sk_lock. During this window, if another thread hold<br /> vsock_register_mutex while trying to acquire sk_lock, a circular<br /> dependency is created.<br /> <br /> Fix this by releasing vsock_register_mutex before calling<br /> transport-&gt;release() and vsock_deassign_transport(). This is safe<br /> because we don&amp;#39;t need to hold vsock_register_mutex while releasing the<br /> old transport, and we ensure the new transport won&amp;#39;t disappear by<br /> obtaining a module reference first via try_module_get().
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40222

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: sh-sci: fix RSCI FIFO overrun handling<br /> <br /> The receive error handling code is shared between RSCI and all other<br /> SCIF port types, but the RSCI overrun_reg is specified as a memory<br /> offset, while for other SCIF types it is an enum value used to index<br /> into the sci_port_params-&gt;regs array, as mentioned above the<br /> sci_serial_in() function.<br /> <br /> For RSCI, the overrun_reg is CSR (0x48), causing the sci_getreg() call<br /> inside the sci_handle_fifo_overrun() function to index outside the<br /> bounds of the regs array, which currently has a size of 20, as specified<br /> by SCI_NR_REGS.<br /> <br /> Because of this, we end up accessing memory outside of RSCI&amp;#39;s<br /> rsci_port_params structure, which, when interpreted as a plat_sci_reg,<br /> happens to have a non-zero size, causing the following WARN when<br /> sci_serial_in() is called, as the accidental size does not match the<br /> supported register sizes.<br /> <br /> The existence of the overrun_reg needs to be checked because<br /> SCIx_SH3_SCIF_REGTYPE has overrun_reg set to SCLSR, but SCLSR is not<br /> present in the regs array.<br /> <br /> Avoid calling sci_getreg() for port types which don&amp;#39;t use standard<br /> register handling.<br /> <br /> Use the ops-&gt;read_reg() and ops-&gt;write_reg() functions to properly read<br /> and write registers for RSCI, and change the type of the status variable<br /> to accommodate the 32-bit CSR register.<br /> <br /> sci_getreg() and sci_serial_in() are also called with overrun_reg in the<br /> sci_mpxed_interrupt() interrupt handler, but that code path is not used<br /> for RSCI, as it does not have a muxed interrupt.<br /> <br /> ------------[ cut here ]------------<br /> Invalid register access<br /> WARNING: CPU: 0 PID: 0 at drivers/tty/serial/sh-sci.c:522 sci_serial_in+0x38/0xac<br /> Modules linked in: renesas_usbhs at24 rzt2h_adc industrialio_adc sha256 cfg80211 bluetooth ecdh_generic ecc rfkill fuse drm backlight ipv6<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.17.0-rc1+ #30 PREEMPT<br /> Hardware name: Renesas RZ/T2H EVK Board based on r9a09g077m44 (DT)<br /> pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : sci_serial_in+0x38/0xac<br /> lr : sci_serial_in+0x38/0xac<br /> sp : ffff800080003e80<br /> x29: ffff800080003e80 x28: ffff800082195b80 x27: 000000000000000d<br /> x26: ffff8000821956d0 x25: 0000000000000000 x24: ffff800082195b80<br /> x23: ffff000180e0d800 x22: 0000000000000010 x21: 0000000000000000<br /> x20: 0000000000000010 x19: ffff000180e72000 x18: 000000000000000a<br /> x17: ffff8002bcee7000 x16: ffff800080000000 x15: 0720072007200720<br /> x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720<br /> x11: 0000000000000058 x10: 0000000000000018 x9 : ffff8000821a6a48<br /> x8 : 0000000000057fa8 x7 : 0000000000000406 x6 : ffff8000821fea48<br /> x5 : ffff00033ef88408 x4 : ffff8002bcee7000 x3 : ffff800082195b80<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800082195b80<br /> Call trace:<br /> sci_serial_in+0x38/0xac (P)<br /> sci_handle_fifo_overrun.isra.0+0x70/0x134<br /> sci_er_interrupt+0x50/0x39c<br /> __handle_irq_event_percpu+0x48/0x140<br /> handle_irq_event+0x44/0xb0<br /> handle_fasteoi_irq+0xf4/0x1a0<br /> handle_irq_desc+0x34/0x58<br /> generic_handle_domain_irq+0x1c/0x28<br /> gic_handle_irq+0x4c/0x140<br /> call_on_irq_stack+0x30/0x48<br /> do_interrupt_handler+0x80/0x84<br /> el1_interrupt+0x34/0x68<br /> el1h_64_irq_handler+0x18/0x24<br /> el1h_64_irq+0x6c/0x70<br /> default_idle_call+0x28/0x58 (P)<br /> do_idle+0x1f8/0x250<br /> cpu_startup_entry+0x34/0x3c<br /> rest_init+0xd8/0xe0<br /> console_on_rootfs+0x0/0x6c<br /> __primary_switched+0x88/0x90<br /> ---[ end trace 0000000000000000 ]---
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40223

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> most: usb: Fix use-after-free in hdm_disconnect<br /> <br /> hdm_disconnect() calls most_deregister_interface(), which eventually<br /> unregisters the MOST interface device with device_unregister(iface-&gt;dev).<br /> If that drops the last reference, the device core may call release_mdev()<br /> immediately while hdm_disconnect() is still executing.<br /> <br /> The old code also freed several mdev-owned allocations in<br /> hdm_disconnect() and then performed additional put_device() calls.<br /> Depending on refcount order, this could lead to use-after-free or<br /> double-free when release_mdev() ran (or when unregister paths also<br /> performed puts).<br /> <br /> Fix by moving the frees of mdev-owned allocations into release_mdev(),<br /> so they happen exactly once when the device is truly released, and by<br /> dropping the extra put_device() calls in hdm_disconnect() that are<br /> redundant after device_unregister() and most_deregister_interface().<br /> <br /> This addresses the KASAN slab-use-after-free reported by syzbot in<br /> hdm_disconnect(). See report and stack traces in the bug link below.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025

CVE-2025-40224

Fecha de publicación:
04/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (cgbc-hwmon) Add missing NULL check after devm_kzalloc()<br /> <br /> The driver allocates memory for sensor data using devm_kzalloc(), but<br /> did not check if the allocation succeeded. In case of memory allocation<br /> failure, dereferencing the NULL pointer would lead to a kernel crash.<br /> <br /> Add a NULL pointer check and return -ENOMEM to handle allocation failure<br /> properly.
Gravedad: Pendiente de análisis
Última modificación:
04/12/2025