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-2022-50654

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix panic due to wrong pageattr of im-&gt;image<br /> <br /> In the scenario where livepatch and kretfunc coexist, the pageattr of<br /> im-&gt;image is rox after arch_prepare_bpf_trampoline in<br /> bpf_trampoline_update, and then modify_fentry or register_fentry returns<br /> -EAGAIN from bpf_tramp_ftrace_ops_func, the BPF_TRAMP_F_ORIG_STACK flag<br /> will be configured, and arch_prepare_bpf_trampoline will be re-executed.<br /> <br /> At this time, because the pageattr of im-&gt;image is rox,<br /> arch_prepare_bpf_trampoline will read and write im-&gt;image, which causes<br /> a fault. as follows:<br /> <br /> insmod livepatch-sample.ko # samples/livepatch/livepatch-sample.c<br /> bpftrace -e &amp;#39;kretfunc:cmdline_proc_show {}&amp;#39;<br /> <br /> BUG: unable to handle page fault for address: ffffffffa0206000<br /> PGD 322d067 P4D 322d067 PUD 322e063 PMD 1297e067 PTE d428061<br /> Oops: 0003 [#1] PREEMPT SMP PTI<br /> CPU: 2 PID: 270 Comm: bpftrace Tainted: G E K 6.1.0 #5<br /> RIP: 0010:arch_prepare_bpf_trampoline+0xed/0x8c0<br /> RSP: 0018:ffffc90001083ad8 EFLAGS: 00010202<br /> RAX: ffffffffa0206000 RBX: 0000000000000020 RCX: 0000000000000000<br /> RDX: ffffffffa0206001 RSI: ffffffffa0206000 RDI: 0000000000000030<br /> RBP: ffffc90001083b70 R08: 0000000000000066 R09: ffff88800f51b400<br /> R10: 000000002e72c6e5 R11: 00000000d0a15080 R12: ffff8880110a68c8<br /> R13: 0000000000000000 R14: ffff88800f51b400 R15: ffffffff814fec10<br /> FS: 00007f87bc0dc780(0000) GS:ffff88803e600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffa0206000 CR3: 0000000010b70000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> bpf_trampoline_update+0x25a/0x6b0<br /> __bpf_trampoline_link_prog+0x101/0x240<br /> bpf_trampoline_link_prog+0x2d/0x50<br /> bpf_tracing_prog_attach+0x24c/0x530<br /> bpf_raw_tp_link_attach+0x73/0x1d0<br /> __sys_bpf+0x100e/0x2570<br /> __x64_sys_bpf+0x1c/0x30<br /> do_syscall_64+0x5b/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> With this patch, when modify_fentry or register_fentry returns -EAGAIN<br /> from bpf_tramp_ftrace_ops_func, the pageattr of im-&gt;image will be reset<br /> to nx+rw.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50655

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: associate skb with a device at tx<br /> <br /> Syzkaller triggered flow dissector warning with the following:<br /> <br /> r0 = openat$ppp(0xffffffffffffff9c, &amp;(0x7f0000000000), 0xc0802, 0x0)<br /> ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &amp;(0x7f00000000c0))<br /> ioctl$PPPIOCSACTIVE(r0, 0x40107446, &amp;(0x7f0000000240)={0x2, &amp;(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})<br /> pwritev(r0, &amp;(0x7f0000000040)=[{&amp;(0x7f0000000140)=&amp;#39;\x00!&amp;#39;, 0x2}], 0x1, 0x0, 0x0)<br /> <br /> [ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0<br /> [ 9.485929] skb_get_poff+0x53/0xa0<br /> [ 9.485937] bpf_skb_get_pay_offset+0xe/0x20<br /> [ 9.485944] ? ppp_send_frame+0xc2/0x5b0<br /> [ 9.485949] ? _raw_spin_unlock_irqrestore+0x40/0x60<br /> [ 9.485958] ? __ppp_xmit_process+0x7a/0xe0<br /> [ 9.485968] ? ppp_xmit_process+0x5b/0xb0<br /> [ 9.485974] ? ppp_write+0x12a/0x190<br /> [ 9.485981] ? do_iter_write+0x18e/0x2d0<br /> [ 9.485987] ? __import_iovec+0x30/0x130<br /> [ 9.485997] ? do_pwritev+0x1b6/0x240<br /> [ 9.486016] ? trace_hardirqs_on+0x47/0x50<br /> [ 9.486023] ? __x64_sys_pwritev+0x24/0x30<br /> [ 9.486026] ? do_syscall_64+0x3d/0x80<br /> [ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Flow dissector tries to find skb net namespace either via device<br /> or via socket. Neigher is set in ppp_send_frame, so let&amp;#39;s manually<br /> use ppp-&gt;dev.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50656

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: pn533: Clear nfc_target before being used<br /> <br /> Fix a slab-out-of-bounds read that occurs in nla_put() called from<br /> nfc_genl_send_target() when target-&gt;sensb_res_len, which is duplicated<br /> from an nfc_target in pn533, is too large as the nfc_target is not<br /> properly initialized and retains garbage values. Clear nfc_targets with<br /> memset() before they are used.<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> BUG: KASAN: slab-out-of-bounds in nla_put<br /> Call Trace:<br /> memcpy<br /> nla_put<br /> nfc_genl_dump_targets<br /> genl_lock_dumpit<br /> netlink_dump<br /> __netlink_dump_start<br /> genl_family_rcv_msg_dumpit<br /> genl_rcv_msg<br /> netlink_rcv_skb<br /> genl_rcv<br /> netlink_unicast<br /> netlink_sendmsg<br /> sock_sendmsg<br /> ____sys_sendmsg<br /> ___sys_sendmsg<br /> __sys_sendmsg<br /> do_syscall_64
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2023-53777

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: kill hooked chains to avoid loops on deduplicated compressed images<br /> <br /> After heavily stressing EROFS with several images which include a<br /> hand-crafted image of repeated patterns for more than 46 days, I found<br /> two chains could be linked with each other almost simultaneously and<br /> form a loop so that the entire loop won&amp;#39;t be submitted. As a<br /> consequence, the corresponding file pages will remain locked forever.<br /> <br /> It can be _only_ observed on data-deduplicated compressed images.<br /> For example, consider two chains with five pclusters in total:<br /> Chain 1: 2-&gt;3-&gt;4-&gt;5 -- The tail pcluster is 5;<br /> Chain 2: 5-&gt;1-&gt;2 -- The tail pcluster is 2.<br /> <br /> Chain 2 could link to Chain 1 with pcluster 5; and Chain 1 could link<br /> to Chain 2 at the same time with pcluster 2.<br /> <br /> Since hooked chains are all linked locklessly now, I have no idea how<br /> to simply avoid the race. Instead, let&amp;#39;s avoid hooked chains completely<br /> until I could work out a proper way to fix this and end users finally<br /> tell us that it&amp;#39;s needed to add it back.<br /> <br /> Actually, this optimization can be found with multi-threaded workloads<br /> (especially even more often on deduplicated compressed images), yet I&amp;#39;m<br /> not sure about the overall system impacts of not having this compared<br /> with implementation complexity.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2023-53778

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Clean up integer overflow checking in map_user_pages()<br /> <br /> The encode_dma() function has some validation on in_trans-&gt;size but it<br /> would be more clear to move those checks to find_and_map_user_pages().<br /> <br /> The encode_dma() had two checks:<br /> <br /> if (in_trans-&gt;addr + in_trans-&gt;size addr || !in_trans-&gt;size)<br /> return -EINVAL;<br /> <br /> The in_trans-&gt;addr variable is the starting address. The in_trans-&gt;size<br /> variable is the total size of the transfer. The transfer can occur in<br /> parts and the resources-&gt;xferred_dma_size tracks how many bytes we have<br /> already transferred.<br /> <br /> This patch introduces a new variable "remaining" which represents the<br /> amount we want to transfer (in_trans-&gt;size) minus the amount we have<br /> already transferred (resources-&gt;xferred_dma_size).<br /> <br /> I have modified the check for if in_trans-&gt;size is zero to instead check<br /> if in_trans-&gt;size is less than resources-&gt;xferred_dma_size. If we have<br /> already transferred more bytes than in_trans-&gt;size then there are negative<br /> bytes remaining which doesn&amp;#39;t make sense. If there are zero bytes<br /> remaining to be copied, just return success.<br /> <br /> The check in encode_dma() checked that "addr + size" could not overflow<br /> and barring a driver bug that should work, but it&amp;#39;s easier to check if<br /> we do this in parts. First check that "in_trans-&gt;addr +<br /> resources-&gt;xferred_dma_size" is safe. Then check that "xfer_start_addr +<br /> remaining" is safe.<br /> <br /> My final concern was that we are dealing with u64 values but on 32bit<br /> systems the kmalloc() function will truncate the sizes to 32 bits. So<br /> I calculated "total = in_trans-&gt;size + offset_in_page(xfer_start_addr);"<br /> and returned -EINVAL if it were &gt;= SIZE_MAX. This will not affect 64bit<br /> systems.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50645

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/i10nm: fix refcount leak in pci_get_dev_wrapper()<br /> <br /> As the comment of pci_get_domain_bus_and_slot() says, it returns<br /> a PCI device with refcount incremented, so it doesn&amp;#39;t need to<br /> call an extra pci_dev_get() in pci_get_dev_wrapper(), and the PCI<br /> device needs to be put in the error path.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50646

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: hpsa: Fix possible memory leak in hpsa_init_one()<br /> <br /> The hpda_alloc_ctlr_info() allocates h and its field reply_map. However, in<br /> hpsa_init_one(), if alloc_percpu() failed, the hpsa_init_one() jumps to<br /> clean1 directly, which frees h and leaks the h-&gt;reply_map.<br /> <br /> Fix by calling hpda_free_ctlr_info() to release h-&gt;replay_map and h instead<br /> free h directly.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50647

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: Make port I/O string accessors actually work<br /> <br /> Fix port I/O string accessors such as `insb&amp;#39;, `outsb&amp;#39;, etc. which use<br /> the physical PCI port I/O address rather than the corresponding memory<br /> mapping to get at the requested location, which in turn breaks at least<br /> accesses made by our parport driver to a PCIe parallel port such as:<br /> <br /> PCI parallel port detected: 1415:c118, I/O at 0x1000(0x1008), IRQ 20<br /> parport0: PC-style at 0x1000 (0x1008), irq 20, using FIFO [PCSPP,TRISTATE,COMPAT,EPP,ECP]<br /> <br /> causing a memory access fault:<br /> <br /> Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000001008<br /> Oops [#1]<br /> Modules linked in:<br /> CPU: 1 PID: 350 Comm: cat Not tainted 6.0.0-rc2-00283-g10d4879f9ef0-dirty #23<br /> Hardware name: SiFive HiFive Unmatched A00 (DT)<br /> epc : parport_pc_fifo_write_block_pio+0x266/0x416<br /> ra : parport_pc_fifo_write_block_pio+0xb4/0x416<br /> epc : ffffffff80542c3e ra : ffffffff80542a8c sp : ffffffd88899fc60<br /> gp : ffffffff80fa2700 tp : ffffffd882b1e900 t0 : ffffffd883d0b000<br /> t1 : ffffffffff000002 t2 : 4646393043330a38 s0 : ffffffd88899fcf0<br /> s1 : 0000000000001000 a0 : 0000000000000010 a1 : 0000000000000000<br /> a2 : ffffffd883d0a010 a3 : 0000000000000023 a4 : 00000000ffff8fbb<br /> a5 : ffffffd883d0a001 a6 : 0000000100000000 a7 : ffffffc800000000<br /> s2 : ffffffffff000002 s3 : ffffffff80d28880 s4 : ffffffff80fa1f50<br /> s5 : 0000000000001008 s6 : 0000000000000008 s7 : ffffffd883d0a000<br /> s8 : 0004000000000000 s9 : ffffffff80dc1d80 s10: ffffffd8807e4000<br /> s11: 0000000000000000 t3 : 00000000000000ff t4 : 393044410a303930<br /> t5 : 0000000000001000 t6 : 0000000000040000<br /> status: 0000000200000120 badaddr: 0000000000001008 cause: 000000000000000f<br /> [] parport_pc_compat_write_block_pio+0xfe/0x200<br /> [] parport_write+0x46/0xf8<br /> [] lp_write+0x158/0x2d2<br /> [] vfs_write+0x8e/0x2c2<br /> [] ksys_write+0x52/0xc2<br /> [] sys_write+0xe/0x16<br /> [] ret_from_syscall+0x0/0x2<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> For simplicity address the problem by adding PCI_IOBASE to the physical<br /> address requested in the respective wrapper macros only, observing that<br /> the raw accessors such as `__insb&amp;#39;, `__outsb&amp;#39;, etc. are not supposed to<br /> be used other than by said macros. Remove the cast to `long&amp;#39; that is no<br /> longer needed on `addr&amp;#39; now that it is used as an offset from PCI_IOBASE<br /> and add parentheses around `addr&amp;#39; needed for predictable evaluation in<br /> macro expansion. No need to make said adjustments in separate changes<br /> given that current code is gravely broken and does not ever work.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50648

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix recursive locking direct_mutex in ftrace_modify_direct_caller<br /> <br /> Naveen reported recursive locking of direct_mutex with sample<br /> ftrace-direct-modify.ko:<br /> <br /> [ 74.762406] WARNING: possible recursive locking detected<br /> [ 74.762887] 6.0.0-rc6+ #33 Not tainted<br /> [ 74.763216] --------------------------------------------<br /> [ 74.763672] event-sample-fn/1084 is trying to acquire lock:<br /> [ 74.764152] ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}, at: \<br /> register_ftrace_function+0x1f/0x180<br /> [ 74.764922]<br /> [ 74.764922] but task is already holding lock:<br /> [ 74.765421] ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}, at: \<br /> modify_ftrace_direct+0x34/0x1f0<br /> [ 74.766142]<br /> [ 74.766142] other info that might help us debug this:<br /> [ 74.766701] Possible unsafe locking scenario:<br /> [ 74.766701]<br /> [ 74.767216] CPU0<br /> [ 74.767437] ----<br /> [ 74.767656] lock(direct_mutex);<br /> [ 74.767952] lock(direct_mutex);<br /> [ 74.768245]<br /> [ 74.768245] *** DEADLOCK ***<br /> [ 74.768245]<br /> [ 74.768750] May be due to missing lock nesting notation<br /> [ 74.768750]<br /> [ 74.769332] 1 lock held by event-sample-fn/1084:<br /> [ 74.769731] #0: ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}, at: \<br /> modify_ftrace_direct+0x34/0x1f0<br /> [ 74.770496]<br /> [ 74.770496] stack backtrace:<br /> [ 74.770884] CPU: 4 PID: 1084 Comm: event-sample-fn Not tainted ...<br /> [ 74.771498] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...<br /> [ 74.772474] Call Trace:<br /> [ 74.772696] <br /> [ 74.772896] dump_stack_lvl+0x44/0x5b<br /> [ 74.773223] __lock_acquire.cold.74+0xac/0x2b7<br /> [ 74.773616] lock_acquire+0xd2/0x310<br /> [ 74.773936] ? register_ftrace_function+0x1f/0x180<br /> [ 74.774357] ? lock_is_held_type+0xd8/0x130<br /> [ 74.774744] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]<br /> [ 74.775213] __mutex_lock+0x99/0x1010<br /> [ 74.775536] ? register_ftrace_function+0x1f/0x180<br /> [ 74.775954] ? slab_free_freelist_hook.isra.43+0x115/0x160<br /> [ 74.776424] ? ftrace_set_hash+0x195/0x220<br /> [ 74.776779] ? register_ftrace_function+0x1f/0x180<br /> [ 74.777194] ? kfree+0x3e1/0x440<br /> [ 74.777482] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]<br /> [ 74.777941] ? __schedule+0xb40/0xb40<br /> [ 74.778258] ? register_ftrace_function+0x1f/0x180<br /> [ 74.778672] ? my_tramp1+0xf/0xf [ftrace_direct_modify]<br /> [ 74.779128] register_ftrace_function+0x1f/0x180<br /> [ 74.779527] ? ftrace_set_filter_ip+0x33/0x70<br /> [ 74.779910] ? __schedule+0xb40/0xb40<br /> [ 74.780231] ? my_tramp1+0xf/0xf [ftrace_direct_modify]<br /> [ 74.780678] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]<br /> [ 74.781147] ftrace_modify_direct_caller+0x5b/0x90<br /> [ 74.781563] ? 0xffffffffa0201000<br /> [ 74.781859] ? my_tramp1+0xf/0xf [ftrace_direct_modify]<br /> [ 74.782309] modify_ftrace_direct+0x1b2/0x1f0<br /> [ 74.782690] ? __schedule+0xb40/0xb40<br /> [ 74.783014] ? simple_thread+0x2a/0xb0 [ftrace_direct_modify]<br /> [ 74.783508] ? __schedule+0xb40/0xb40<br /> [ 74.783832] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]<br /> [ 74.784294] simple_thread+0x76/0xb0 [ftrace_direct_modify]<br /> [ 74.784766] kthread+0xf5/0x120<br /> [ 74.785052] ? kthread_complete_and_exit+0x20/0x20<br /> [ 74.785464] ret_from_fork+0x22/0x30<br /> [ 74.785781] <br /> <br /> Fix this by using register_ftrace_function_nolock in<br /> ftrace_modify_direct_caller.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50649

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: adp5061: fix out-of-bounds read in adp5061_get_chg_type()<br /> <br /> ADP5061_CHG_STATUS_1_CHG_STATUS is masked with 0x07, which means a length<br /> of 8, but adp5061_chg_type array size is 4, may end up reading 4 elements<br /> beyond the end of the adp5061_chg_type[] array.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50650

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix reference state management for synchronous callbacks<br /> <br /> Currently, verifier verifies callback functions (sync and async) as if<br /> they will be executed once, (i.e. it explores execution state as if the<br /> function was being called once). The next insn to explore is set to<br /> start of subprog and the exit from nested frame is handled using<br /> curframe &gt; 0 and prepare_func_exit. In case of async callback it uses a<br /> customized variant of push_stack simulating a kind of branch to set up<br /> custom state and execution context for the async callback.<br /> <br /> While this approach is simple and works when callback really will be<br /> executed only once, it is unsafe for all of our current helpers which<br /> are for_each style, i.e. they execute the callback multiple times.<br /> <br /> A callback releasing acquired references of the caller may do so<br /> multiple times, but currently verifier sees it as one call inside the<br /> frame, which then returns to caller. Hence, it thinks it released some<br /> reference that the cb e.g. got access through callback_ctx (register<br /> filled inside cb from spilled typed register on stack).<br /> <br /> Similarly, it may see that an acquire call is unpaired inside the<br /> callback, so the caller will copy the reference state of callback and<br /> then will have to release the register with new ref_obj_ids. But again,<br /> the callback may execute multiple times, but the verifier will only<br /> account for acquired references for a single symbolic execution of the<br /> callback, which will cause leaks.<br /> <br /> Note that for async callback case, things are different. While currently<br /> we have bpf_timer_set_callback which only executes it once, even for<br /> multiple executions it would be safe, as reference state is NULL and<br /> check_reference_leak would force program to release state before<br /> BPF_EXIT. The state is also unaffected by analysis for the caller frame.<br /> Hence async callback is safe.<br /> <br /> Since we want the reference state to be accessible, e.g. for pointers<br /> loaded from stack through callback_ctx&amp;#39;s PTR_TO_STACK, we still have to<br /> copy caller&amp;#39;s reference_state to callback&amp;#39;s bpf_func_state, but we<br /> enforce that whatever references it adds to that reference_state has<br /> been released before it hits BPF_EXIT. This requires introducing a new<br /> callback_ref member in the reference state to distinguish between caller<br /> vs callee references. Hence, check_reference_leak now errors out if it<br /> sees we are in callback_fn and we have not released callback_ref refs.<br /> Since there can be multiple nested callbacks, like frame 0 -&gt; cb1 -&gt; cb2<br /> etc. we need to also distinguish between whether this particular ref<br /> belongs to this callback frame or parent, and only error for our own, so<br /> we store state-&gt;frameno (which is always non-zero for callbacks).<br /> <br /> In short, callbacks can read parent reference_state, but cannot mutate<br /> it, to be able to use pointers acquired by the caller. They must only<br /> undo their changes (by releasing their own acquired_refs before<br /> BPF_EXIT) on top of caller reference_state before returning (at which<br /> point the caller and callback state will match anyway, so no need to<br /> copy it back to caller).
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025

CVE-2022-50651

Fecha de publicación:
09/12/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: eeprom: fix null-deref on genl_info in dump<br /> <br /> The similar fix as commit 46cdedf2a0fa ("ethtool: pse-pd: fix null-deref on<br /> genl_info in dump") is also needed for ethtool eeprom.
Gravedad: Pendiente de análisis
Última modificación:
09/12/2025