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 últimas 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 últimas 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 últimas vulnerabilidades incorporadas al repositorio.

CVE-2026-63823

Fecha de publicación:
19/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> keys: Pin request_key_auth payload in instantiate paths<br /> <br /> A: request_key() B: KEYCTL_INSTANTIATE_IOV<br /> ================ =========================<br /> <br /> create auth key<br /> store rka in auth key<br /> wait for helper<br /> get auth key<br /> load rka from auth key<br /> copy user payload<br /> sleep on #PF<br /> <br /> helper completed<br /> detach and free rka<br /> destroy auth key<br /> wake up<br /> use rka-&gt;target_key<br /> **USE-AFTER-FREE**<br /> <br /> Give request_key_auth payloads a refcount. Take a payload reference while<br /> authkey-&gt;sem stabilizes the payload and revocation state. Hold that<br /> reference across the instantiate and reject paths. Drop the auth key<br /> owning reference from revoke and destroy.<br /> <br /> [jarkko: Replaced the first two paragraphs of text with an actual<br /> concurrency scenario.]
Gravedad: Pendiente de análisis
Última modificación:
19/07/2026

CVE-2026-63824

Fecha de publicación:
19/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KEYS: fix overflow in keyctl_pkey_params_get_2()<br /> <br /> The length for the internal output buffer is calculated incorrectly, which<br /> can result overflow when a too small buffer is provided.<br /> <br /> Fix the bug by allocating internal output with the size of the maximum<br /> length of the cryptographic primitive instead of caller provided size.
Gravedad: Pendiente de análisis
Última modificación:
19/07/2026

CVE-2026-63825

Fecha de publicación:
19/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gcov: use atomic counter updates to fix concurrent access crashes<br /> <br /> GCC&amp;#39;s GCOV instrumentation can merge global branch counters with loop<br /> induction variables as an optimization. In inflate_fast(), the inner copy<br /> loops get transformed so that the GCOV counter value is loaded multiple<br /> times to compute the loop base address, start index, and end bound. Since<br /> GCOV counters are global (not per-CPU), concurrent execution on different<br /> CPUs causes the counter to change between loads, producing inconsistent<br /> values and out-of-bounds memory writes.<br /> <br /> The crash manifests during IPComp (IP Payload Compression) processing when<br /> inflate_fast() runs concurrently on multiple CPUs:<br /> <br /> BUG: unable to handle page fault for address: ffffd0a3c0902ffa<br /> RIP: inflate_fast+1431<br /> Call Trace:<br /> zlib_inflate<br /> __deflate_decompress<br /> crypto_comp_decompress<br /> ipcomp_decompress [xfrm_ipcomp]<br /> ipcomp_input [xfrm_ipcomp]<br /> xfrm_input<br /> <br /> At the crash point, the compiler generated three loads from the same<br /> global GCOV counter (__gcov0.inflate_fast+216) to compute base, start, and<br /> end for an indexed loop. Another CPU modified the counter between loads,<br /> making the values inconsistent - the write went 3.4 MB past a 65 KB<br /> buffer.<br /> <br /> Add -fprofile-update=prefer-atomic to CFLAGS_GCOV at the global level in<br /> the top-level Makefile, guarded by a try-run compile test. The test<br /> compiles a minimal program with and without -fprofile-update=prefer-atomic<br /> using the full KBUILD_CFLAGS, then compares undefined symbols in the<br /> resulting object files. If prefer-atomic introduces new undefined<br /> references (such as __atomic_fetch_add_8 on i386 or __aarch64_ldadd8_relax<br /> on arm64 with outline-atomics), the flag is not added -- the kernel does<br /> not link against libatomic.<br /> <br /> On architectures where GCC inlines 64-bit atomic counter updates (x86_64,<br /> s390, ...) the test passes and the flag is enabled, preventing the<br /> compiler from merging counters with loop induction variables and fixing<br /> the observed concurrent-access crash.<br /> <br /> On architectures where the flag would introduce libatomic dependencies, it<br /> is silently omitted and behaviour is no worse than before this patch.<br /> <br /> Move the CFLAGS_GCOV block from its original position (before the arch<br /> Makefile include) to after the core KBUILD_CFLAGS assignments but before<br /> the scripts/Makefile.gcc-plugins include. This placement ensures the<br /> try-run test sees arch-specific flags (-m32, -march=,<br /> -mno-outline-atomics) while avoiding GCC plugin flags (-fplugin=) that<br /> would break the test on clean builds when plugin shared objects do not yet<br /> exist.
Gravedad: Pendiente de análisis
Última modificación:
19/07/2026

CVE-2026-63826

Fecha de publicación:
19/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: fix use-after-free in store_modes()<br /> <br /> store_modes() replaces a framebuffer&amp;#39;s modelist with modes from userspace.<br /> On success it frees the old modelist with fb_destroy_modelist(). Two<br /> fields still point into that freed list.<br /> <br /> One pointer is fb_display[i].mode, the mode a console is using.<br /> fbcon_new_modelist() moves these pointers to the new list. It only does so<br /> for consoles still mapped to the framebuffer. An unmapped console is<br /> skipped and keeps its stale pointer. Unbinding fbcon, for example, sets<br /> con2fb_map[i] to -1 but leaves fb_display[i].mode set. An<br /> FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches<br /> fbcon_mode_deleted(). That function reads the stale fb_display[i].mode<br /> through fb_mode_is_equal(). The read is a use-after-free.<br /> <br /> The other pointer is fb_info-&gt;mode, the current mode. It is set through<br /> the mode sysfs attribute. store_modes() does not update fb_info-&gt;mode, so<br /> it is left pointing into the freed list. show_mode(), the attribute&amp;#39;s read<br /> handler, dereferences the stale fb_info-&gt;mode through mode_string(). The<br /> read is a use-after-free.<br /> <br /> Clear both pointers before freeing the list. Commit a1f305893074 ("fbcon:<br /> Set fb_display[i]-&gt;mode to NULL when the mode is released") added the<br /> helper fbcon_delete_modelist(). It clears every fb_display[i].mode that<br /> points into a given list. So far it is called only from the unregister<br /> path. Call it from store_modes() too, and set fb_info-&gt;mode to NULL.
Gravedad: Pendiente de análisis
Última modificación:
19/07/2026

CVE-2026-63827

Fecha de publicación:
19/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix use-after-free in rawdata dedup loop<br /> <br /> aa_replace_profiles() walks ns-&gt;rawdata_list to dedup the incoming<br /> policy blob against entries already attached to existing profiles.<br /> Per the kernel-doc on struct aa_loaddata, list membership does not<br /> hold a reference: profiles hold pcount, and when the last pcount<br /> drops, do_ploaddata_rmfs() is queued on a workqueue that takes<br /> ns-&gt;lock and removes the entry. Between dropping the last pcount<br /> and the workqueue running, an entry remains on the list with<br /> pcount == 0.<br /> <br /> aa_get_profile_loaddata() is an unconditional kref_get() on<br /> pcount, so when the dedup loop hits such an entry, refcount<br /> hardening reports<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> <br /> inside aa_replace_profiles(), and the poisoned counter then<br /> trips "saturated" and "underflow" warnings on the subsequent<br /> uses of the same loaddata.<br /> <br /> Before commit a0b7091c4de4 ("apparmor: fix race on rawdata<br /> dereference") the dedup path used a get_unless_zero-style helper<br /> on a single counter, so the existing "if (tmp)" guard was<br /> meaningful. The split-refcount refactor introduced<br /> aa_get_profile_loaddata(), which has plain kref_get() semantics,<br /> and the guard quietly became a no-op.<br /> <br /> Introduce aa_get_profile_loaddata_not0(), matching the existing<br /> _not0 convention used by aa_get_profile_not0(), and use it for<br /> the rawdata_list dedup lookup so dying entries are skipped.<br /> <br /> Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu<br /> 24.04 + stress-ng 0.17.06:<br /> <br /> stress-ng --apparmor 1 --klog-check --timeout 60s<br /> <br /> Without this patch the three refcount_t warnings fire within a<br /> few seconds. With it the same 60 s run is clean. Coverage is a<br /> smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN<br /> and CONFIG_PROVE_LOCKING would be welcome from anyone with the<br /> cycles.
Gravedad: Pendiente de análisis
Última modificación:
19/07/2026

CVE-2026-63811

Fecha de publicación:
19/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: read COW data with the original inode during atomic write<br /> <br /> When updating an atomic-write file, f2fs_write_begin() may read the<br /> previously written data back from the COW inode:<br /> prepare_atomic_write_begin() locates the block in the COW inode and sets<br /> use_cow, and the read bio is then built with the COW inode:<br /> <br /> f2fs_submit_page_read(use_cow ? F2FS_I(inode)-&gt;cow_inode : inode,<br /> ...);<br /> <br /> and f2fs_grab_read_bio() decides whether to schedule fs-layer decryption<br /> (STEP_DECRYPT) for the bio based on that inode via<br /> fscrypt_inode_uses_fs_layer_crypto().<br /> <br /> However, the folio being filled belongs to the original inode<br /> (folio-&gt;mapping-&gt;host == inode), and the data stored in the COW block was<br /> encrypted (or left as plaintext) using the original inode&amp;#39;s context, not<br /> the COW inode&amp;#39;s -- see f2fs_encrypt_one_page(), which keys off<br /> fio-&gt;page-&gt;mapping-&gt;host. fscrypt_decrypt_pagecache_blocks() likewise<br /> operates on folio-&gt;mapping-&gt;host.<br /> <br /> The COW inode is created as a tmpfile in the parent directory and inherits<br /> its encryption policy from there. With test_dummy_encryption the newly<br /> created COW inode gets the dummy policy and becomes encrypted, while a<br /> pre-existing regular file -- created before the policy applied, e.g.<br /> already present in the on-disk image -- stays unencrypted. The read<br /> path then sets STEP_DECRYPT based on the encrypted COW inode and calls<br /> fscrypt_decrypt_pagecache_blocks() on a folio whose host (the unencrypted<br /> original inode) has a NULL -&gt;i_crypt_info, dereferencing it:<br /> <br /> Oops: general protection fault, probably for non-canonical address ...<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> RIP: 0010:fscrypt_decrypt_pagecache_blocks+0xa0/0x310<br /> Workqueue: f2fs_post_read_wq f2fs_post_read_work<br /> Call Trace:<br /> fscrypt_decrypt_bio+0x1eb/0x340<br /> f2fs_post_read_work+0xba/0x140<br /> process_one_work+0x91c/0x1a40<br /> worker_thread+0x677/0xe90<br /> kthread+0x2bc/0x3a0<br /> <br /> The COW inode is only needed to locate the on-disk block, and that block<br /> address is already resolved into @blkaddr by prepare_atomic_write_begin()<br /> via __find_data_block(cow_inode, ...); f2fs_submit_page_read() then reads<br /> from that physical @blkaddr directly, so the inode argument only selects<br /> the post-read crypto context, not which block is fetched. Reading with<br /> @inode therefore returns the same (latest, not-yet-committed) COW data,<br /> while making both the fs-layer decryption decision and the inline crypto<br /> path use the correct (original inode&amp;#39;s) key.<br /> <br /> With the COW inode no longer used at the read site, the use_cow flag has no<br /> remaining consumer; drop it from f2fs_write_begin() and<br /> prepare_atomic_write_begin().
Gravedad: Pendiente de análisis
Última modificación:
19/07/2026

CVE-2026-63812

Fecha de publicación:
19/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()<br /> <br /> When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does<br /> not reset the length of the largest extent to 0 and update the inode<br /> folio. Since modifications to the extent tree are disallowed afterward,<br /> the cached largest extent may become stale. This can trigger the<br /> following error in xfstests generic/388:<br /> <br /> F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix<br /> <br /> In the f2fs_drop_inode path, __destroy_extent_node() does not need to<br /> guarantee that et-&gt;node_cnt is 0, because concurrency with writeback<br /> is expected in this path, and writeback may update the extent cache.<br /> <br /> This patch reverts commit ed78aeebef05 ("f2fs: fix node_cnt race between<br /> extent node destroy and writeback"), and remove the unnecessary zero<br /> check of et-&gt;node_cnt.
Gravedad: Pendiente de análisis
Última modificación:
19/07/2026

CVE-2026-63813

Fecha de publicación:
19/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "f2fs: remove non-uptodate folio from the page cache in move_data_block"<br /> <br /> This reverts commit 9609dd704725a40cd63d915f2ab6c44248a44598.<br /> <br /> The kernel panics are keeping to be reported especially when the f2fs<br /> partition get almost full. By investigation, we find that the reason is<br /> one f2fs page got freed to buddy without being deleted from LRU and the<br /> root cause is the race happened in [2] which is enrolled by this commit.<br /> <br /> There are 3 race processes in this scenario, please find below for their<br /> main activities.<br /> <br /> The changed code in move_data_block() lets the GC path evict the tail-end<br /> folio from the page cache through folio_end_dropbehind(). Once<br /> folio_unmap_invalidate() removes the folio from mapping-&gt;i_pages, the<br /> page-cache references for all pages in the folio are dropped. The folio<br /> is then kept alive only by temporary external references, which allows a<br /> later split to operate on a folio whose subpages are no longer protected<br /> by page-cache references.<br /> <br /> After the page-cache references are gone, split_folio_to_order() can<br /> split the big folio into individual pages and put the resulting subpages<br /> back on the LRU. For tail pages beyond EOF, split removes them from the<br /> page cache and drops their page-cache references. A tail page can then<br /> remain on the LRU with PG_lru set while holding only the split caller&amp;#39;s<br /> temporary reference. When free_folio_and_swap_cache() drops that final<br /> reference, the page enters the final folio_put() release path.<br /> <br /> In parallel, folio_isolate_lru() can observe the same tail page with a<br /> non-zero refcount and PG_lru set. It clears PG_lru before taking its own<br /> reference. If this races with the final folio_put() from the split path,<br /> __folio_put() sees PG_lru already cleared and skips lruvec_del_folio().<br /> The page is then freed back to the allocator while its lru links are<br /> still present in the LRU list. A later LRU operation on a neighboring<br /> page detects the stale link and reports list corruption.<br /> <br /> [1]<br /> [ 22.486082] list_del corruption. next-&gt;prev should be fffffffec10e0ac8, but was dead000000000122. (next=fffffffec10e0a88)<br /> [ 22.486130] ------------[ cut here ]------------<br /> [ 22.486134] kernel BUG at lib/list_debug.c:67!<br /> [ 22.486141] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> [ 22.488502] Tainted: [W]=WARN, [O]=OOT_MODULE<br /> [ 22.488506] Hardware name: Spreadtrum UMS9230 1H10 SoC (DT)<br /> [ 22.488511] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 22.488517] pc : __list_del_entry_valid_or_report+0x14c/0x154<br /> [ 22.488531] lr : __list_del_entry_valid_or_report+0x14c/0x154<br /> [ 22.488539] sp : ffffffc08006b830<br /> [ 22.488542] x29: ffffffc08006b868 x28: 0000000000003020 x27: 0000000000000000<br /> [ 22.488553] x26: 0000000000000000 x25: 0000000000000004 x24: fffffffec10e0ac0<br /> [ 22.488564] x23: 00000000000000e8 x22: 0000000000000024 x21: dead000000000122<br /> [ 22.488574] x20: fffffffec10e0a88 x19: fffffffec10e0ac8 x18: ffffffc080061060<br /> [ 22.488585] x17: 20747562202c3863 x16: 6130653031636566 x15: 0000000000000058<br /> [ 22.488595] x14: 0000000000000004 x13: ffffff80f91e0000 x12: 0000000000000003<br /> [ 22.488605] x11: 0000000000000003 x10: 0000000000000001 x9 : ffe85721f0e25f00<br /> [ 22.488615] x8 : ffe85721f0e25f00 x7 : 0000000000000000 x6 : 6c65645f7473696c<br /> [ 22.488625] x5 : ffffffed39b23026 x4 : 0000000000000000 x3 : 0000000000000010<br /> [ 22.488636] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000006d<br /> [ 22.488647] Call trace:<br /> [ 22.488651] __list_del_entry_valid_or_report+0x14c/0x154 (P)<br /> [ 22.488661] __folio_put+0x2bc/0x434<br /> [ 22.488670] folio_put+0x28/0x58<br /> [ 22.488678] do_garbage_collect+0x1a34/0x2584<br /> [ 22.488689] f2fs_gc+0x230/0x9b4<br /> [ 22.488697] f2fs_fallocate+0xb90/0xdf4<br /> [ 22.488706] vfs_fallocate+0x1b4/0x2bc<br /> [ 22.488716] __arm64_sys_fallocate+0x44/0x78<br /> [ 22.488725] invoke_syscall+0x58/0xe4<br /> [ 22.488732] do_el0_svc+0x48/0xdc<br /> [ 22.488739] el0<br /> ---truncated---
Gravedad: Pendiente de análisis
Última modificación:
19/07/2026

CVE-2026-63814

Fecha de publicación:
19/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: validate ACL entry sizes in f2fs_acl_from_disk()<br /> <br /> f2fs_acl_count() only validates the aggregate ACL xattr length. A<br /> malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only<br /> contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk()<br /> then reads entry-&gt;e_id before verifying that a full entry fits.<br /> <br /> Require a short entry before reading e_tag and e_perm, and require a<br /> full entry before reading e_id for ACL_USER and ACL_GROUP. Return<br /> -EFSCORRUPTED from these new truncated-entry checks, while keeping the<br /> pre-existing -EINVAL paths unchanged.<br /> <br /> Validation reproduced this kernel report:<br /> KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0<br /> RIP: 0033:0x7f4b835ea7aa<br /> The buggy address belongs to the object at ffff888114589960 which belongs<br /> to the cache kmalloc-8 of size 8<br /> The buggy address is located 0 bytes to the right of allocated 8-byte<br /> region [ffff888114589960, ffff888114589968)<br /> Read of size 4<br /> Call trace:<br /> dump_stack_lvl+0x66/0xa0 (?:?)<br /> print_report+0xce/0x630 (?:?)<br /> __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169)<br /> srso_alias_return_thunk+0x5/0xfbef5 (?:?)<br /> __virt_addr_valid+0x224/0x430 (?:?)<br /> kasan_report+0xe0/0x110 (?:?)<br /> __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169)<br /> __get_acl+0x281/0x380 (?:?)<br /> vfs_get_acl+0x10b/0x190 (?:?)<br /> do_get_acl+0x2a/0x410 (?:?)<br /> do_get_acl+0x9/0x410 (?:?)<br /> do_getxattr+0xe8/0x260 (?:?)<br /> filename_getxattr+0xd1/0x140 (?:?)<br /> do_getname+0x2d/0x2d0 (?:?)<br /> path_getxattrat+0x16c/0x200 (?:?)<br /> lock_release+0xc8/0x290 (?:?)<br /> cgroup_update_frozen+0x9d/0x320 (?:?)<br /> lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?)<br /> trace_hardirqs_on+0x1a/0x170 (?:?)<br /> _raw_spin_unlock_irq+0x28/0x50 (?:?)<br /> do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)
Gravedad: Pendiente de análisis
Última modificación:
19/07/2026

CVE-2026-63815

Fecha de publicación:
19/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: bound i_inline_xattr_size for non-inline-xattr inodes<br /> <br /> When the flexible_inline_xattr feature is enabled, do_read_inode() loads<br /> the on-disk i_inline_xattr_size unconditionally:<br /> <br /> if (f2fs_sb_has_flexible_inline_xattr(sbi))<br /> fi-&gt;i_inline_xattr_size = le16_to_cpu(ri-&gt;i_inline_xattr_size);<br /> <br /> but sanity_check_inode() only range-checks it when the inode also has the<br /> FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline<br /> data but not FI_INLINE_XATTR -- the normal layout for an inline<br /> directory -- therefore keeps a fully attacker-controlled<br /> i_inline_xattr_size from a crafted image.<br /> <br /> get_inline_xattr_addrs() returns that value with no flag gating, so it<br /> feeds the inode geometry:<br /> <br /> MAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1)<br /> NR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...)<br /> addrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size<br /> <br /> A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY()<br /> negative, so make_dentry_ptr_inline() sets d-&gt;max (int) to a negative<br /> value. The inline directory walk then compares an unsigned long bit_pos<br /> against that negative d-&gt;max, which is promoted to a huge unsigned bound,<br /> and reads far past the inline area:<br /> <br /> while (bit_pos max) /* fs/f2fs/dir.c */<br /> ... test_bit_le(bit_pos, d-&gt;bitmap) / d-&gt;dentry[bit_pos] ...<br /> <br /> Mounting a crafted image and reading such a directory triggers an<br /> out-of-bounds read in f2fs_fill_dentries(); the same underflow also<br /> corrupts ADDRS_PER_INODE for regular files.<br /> <br /> Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the<br /> flexible_inline_xattr feature is enabled -- i.e. whenever the value is<br /> loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE<br /> bound gated on inodes that actually carry an inline xattr, so legitimate<br /> inodes with i_inline_xattr_size == 0 are still accepted.
Gravedad: Pendiente de análisis
Última modificación:
19/07/2026

CVE-2026-63816

Fecha de publicación:
19/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode<br /> <br /> - ioctl(F2FS_IOC_GARBAGE_COLLECT_RANGE) - shrink<br /> - f2fs_gc<br /> - gc_data_segment<br /> - ra_data_block(cow_inode)<br /> - mapping = F2FS_I(inode)-&gt;atomic_inode-&gt;i_mapping<br /> : f2fs_is_cow_file(cow_inode) is true<br /> - f2fs_evict_inode(atomic_inode)<br /> - clear_inode_flag(fi-&gt;cow_inode, FI_COW_FILE)<br /> - F2FS_I(fi-&gt;cow_inode)-&gt;atomic_inode = NULL<br /> ...<br /> - truncate_inode_pages_final(atomic_inode)<br /> - f2fs_grab_cache_folio(mapping)<br /> : create folio in atomic_inode-&gt;mapping<br /> - clear_inode(atomic_inode)<br /> - BUG_ON(atomic_inode-&gt;i_data.nrpages)<br /> <br /> We need to add a reference on fi-&gt;atomic_inode before using its mapping<br /> field during garbage collection, otherwise, it will cause UAF issue.
Gravedad: Pendiente de análisis
Última modificación:
19/07/2026

CVE-2026-63817

Fecha de publicación:
19/07/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: validate compress cache inode only when enabled<br /> <br /> F2FS_COMPRESS_INO() uses NM_I(sbi)-&gt;max_nid as the synthetic inode<br /> number for the compressed page cache inode. That inode only exists when<br /> the compress_cache mount option is enabled.<br /> <br /> When compress_cache is disabled, max_nid is outside the valid inode<br /> range. A corrupted directory entry that points to ino == max_nid should<br /> therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino()<br /> currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally,<br /> so f2fs_iget() bypasses do_read_inode() and its nid range check, and<br /> instantiates a fake internal inode instead.<br /> <br /> Gate the compressed cache inode case on COMPRESS_CACHE, matching<br /> f2fs_init_compress_inode(). With compress_cache disabled, ino ==<br /> max_nid now follows the normal inode path and is rejected as an<br /> out-of-range nid.
Gravedad: Pendiente de análisis
Última modificación:
19/07/2026