Vulnerabilities

With the aim of informing, warning and helping professionals with the latest security vulnerabilities in technology systems, we have made a database available for users interested in this information, which is in Spanish and includes all of the latest documented and recognised vulnerabilities.

This repository, with over 75,000 registers, is based on the information from the NVD (National Vulnerability Database) – by virtue of a partnership agreement – through which INCIBE translates the included information into Spanish.

On occasions this list will show vulnerabilities that have still not been translated, as they are added while the INCIBE team is still carrying out the translation process. The CVE  (Common Vulnerabilities and Exposures) Standard for Information Security Vulnerability Names is used with the aim to support the exchange of information between different tools and databases.

All vulnerabilities collected are linked to different information sources, as well as available patches or solutions provided by manufacturers and developers. It is possible to carry out advanced searches, as there is the option to select different criteria to narrow down the results, some examples being vulnerability types, manufacturers and impact levels, among others.

Through RSS feeds or Newsletters we can be informed daily about the latest vulnerabilities added to the repository. Below there is a list, updated daily, where you can discover the latest vulnerabilities.

CVE-2025-38249

Publication date:
09/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()<br /> <br /> In snd_usb_get_audioformat_uac3(), the length value returned from<br /> snd_usb_ctl_msg() is used directly for memory allocation without<br /> validation. This length is controlled by the USB device.<br /> <br /> The allocated buffer is cast to a uac3_cluster_header_descriptor<br /> and its fields are accessed without verifying that the buffer<br /> is large enough. If the device returns a smaller than expected<br /> length, this leads to an out-of-bounds read.<br /> <br /> Add a length check to ensure the buffer is large enough for<br /> uac3_cluster_header_descriptor.
Severity CVSS v4.0: Pending analysis
Last modification:
09/07/2025

CVE-2025-38250

Publication date:
09/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_core: Fix use-after-free in vhci_flush()<br /> <br /> syzbot reported use-after-free in vhci_flush() without repro. [0]<br /> <br /> From the splat, a thread close()d a vhci file descriptor while<br /> its device was being used by iotcl() on another thread.<br /> <br /> Once the last fd refcnt is released, vhci_release() calls<br /> hci_unregister_dev(), hci_free_dev(), and kfree() for struct<br /> vhci_data, which is set to hci_dev-&gt;dev-&gt;driver_data.<br /> <br /> The problem is that there is no synchronisation after unlinking<br /> hdev from hci_dev_list in hci_unregister_dev(). There might be<br /> another thread still accessing the hdev which was fetched before<br /> the unlink operation.<br /> <br /> We can use SRCU for such synchronisation.<br /> <br /> Let&amp;#39;s run hci_dev_reset() under SRCU and wait for its completion<br /> in hci_unregister_dev().<br /> <br /> Another option would be to restore hci_dev-&gt;destruct(), which was<br /> removed in commit 587ae086f6e4 ("Bluetooth: Remove unused<br /> hci-destruct cb"). However, this would not be a good solution, as<br /> we should not run hci_unregister_dev() while there are in-flight<br /> ioctl() requests, which could lead to another data-race KCSAN splat.<br /> <br /> Note that other drivers seem to have the same problem, for exmaple,<br /> virtbt_remove().<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]<br /> BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937<br /> Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718<br /> <br /> CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xd2/0x2b0 mm/kasan/report.c:521<br /> kasan_report+0x118/0x150 mm/kasan/report.c:634<br /> skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]<br /> skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937<br /> skb_queue_purge include/linux/skbuff.h:3368 [inline]<br /> vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69<br /> hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline]<br /> hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592<br /> sock_do_ioctl+0xd9/0x300 net/socket.c:1190<br /> sock_ioctl+0x576/0x790 net/socket.c:1311<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fcf5b98e929<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929<br /> RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009<br /> RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528<br /> <br /> <br /> Allocated by task 6535:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359<br /> kmalloc_noprof include/linux/slab.h:905 [inline]<br /> kzalloc_noprof include/linux/slab.h:1039 [inline]<br /> vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635<br /> misc_open+0x2bc/0x330 drivers/char/misc.c:161<br /> chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414<br /> do_dentry_open+0xdf0/0x1970 fs/open.c:964<br /> vfs_open+0x3b/0x340 fs/open.c:1094<br /> do_open fs/namei.c:3887 [inline]<br /> path_openat+0x2ee5/0x3830 fs/name<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
09/07/2025

CVE-2025-38251

Publication date:
09/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: clip: prevent NULL deref in clip_push()<br /> <br /> Blamed commit missed that vcc_destroy_socket() calls<br /> clip_push() with a NULL skb.<br /> <br /> If clip_devs is NULL, clip_push() then crashes when reading<br /> skb-&gt;truesize.
Severity CVSS v4.0: Pending analysis
Last modification:
09/07/2025

CVE-2025-38252

Publication date:
09/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/ras: Fix CPER handler device confusion<br /> <br /> By inspection, cxl_cper_handle_prot_err() is making a series of fragile<br /> assumptions that can lead to crashes:<br /> <br /> 1/ It assumes that endpoints identified in the record are a CXL-type-3<br /> device, nothing guarantees that.<br /> <br /> 2/ It assumes that the device is bound to the cxl_pci driver, nothing<br /> guarantees that.<br /> <br /> 3/ Minor, it holds the device lock over the switch-port tracing for no<br /> reason as the trace is 100% generated from data in the record.<br /> <br /> Correct those by checking that the PCIe endpoint parents a cxl_memdev<br /> before assuming the format of the driver data, and move the lock to where<br /> it is required. Consequently this also makes the implementation ready for<br /> CXL accelerators that are not bound to cxl_pci.
Severity CVSS v4.0: Pending analysis
Last modification:
09/07/2025

CVE-2025-38253

Publication date:
09/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: wacom: fix crash in wacom_aes_battery_handler()<br /> <br /> Commit fd2a9b29dc9c ("HID: wacom: Remove AES power_supply after extended<br /> inactivity") introduced wacom_aes_battery_handler() which is scheduled<br /> as a delayed work (aes_battery_work).<br /> <br /> In wacom_remove(), aes_battery_work is not canceled. Consequently, if<br /> the device is removed while aes_battery_work is still pending, then hard<br /> crashes or "Oops: general protection fault..." are experienced when<br /> wacom_aes_battery_handler() is finally called. E.g., this happens with<br /> built-in USB devices after resume from hibernate when aes_battery_work<br /> was still pending at the time of hibernation.<br /> <br /> So, take care to cancel aes_battery_work in wacom_remove().
Severity CVSS v4.0: Pending analysis
Last modification:
09/07/2025

CVE-2025-38254

Publication date:
09/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add sanity checks for drm_edid_raw()<br /> <br /> When EDID is retrieved via drm_edid_raw(), it doesn&amp;#39;t guarantee to<br /> return proper EDID bytes the caller wants: it may be either NULL (that<br /> leads to an Oops) or with too long bytes over the fixed size raw_edid<br /> array (that may lead to memory corruption). The latter was reported<br /> actually when connected with a bad adapter.<br /> <br /> Add sanity checks for drm_edid_raw() to address the above corner<br /> cases, and return EDID_BAD_INPUT accordingly.<br /> <br /> (cherry picked from commit 648d3f4d209725d51900d6a3ed46b7b600140cdf)
Severity CVSS v4.0: Pending analysis
Last modification:
09/07/2025

CVE-2025-38255

Publication date:
09/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()<br /> <br /> While testing null_blk with configfs, echo 0 &gt; poll_queues will trigger<br /> following panic:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014<br /> RIP: 0010:__bitmap_or+0x48/0x70<br /> Call Trace:<br /> <br /> __group_cpus_evenly+0x822/0x8c0<br /> group_cpus_evenly+0x2d9/0x490<br /> blk_mq_map_queues+0x1e/0x110<br /> null_map_queues+0xc9/0x170 [null_blk]<br /> blk_mq_update_queue_map+0xdb/0x160<br /> blk_mq_update_nr_hw_queues+0x22b/0x560<br /> nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]<br /> nullb_device_poll_queues_store+0xa4/0x130 [null_blk]<br /> configfs_write_iter+0x109/0x1d0<br /> vfs_write+0x26e/0x6f0<br /> ksys_write+0x79/0x180<br /> __x64_sys_write+0x1d/0x30<br /> x64_sys_call+0x45c4/0x45f0<br /> do_syscall_64+0xa5/0x240<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Root cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned from<br /> kcalloc(), and later ZERO_SIZE_PTR will be deferenced.<br /> <br /> Fix the problem by checking numgrps first in group_cpus_evenly(), and<br /> return NULL directly if numgrps is zero.<br /> <br /> [yukuai3@huawei.com: also fix the non-SMP version]
Severity CVSS v4.0: Pending analysis
Last modification:
09/07/2025

CVE-2025-38256

Publication date:
09/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rsrc: fix folio unpinning<br /> <br /> syzbot complains about an unmapping failure:<br /> <br /> [ 108.070381][ T14] kernel BUG at mm/gup.c:71!<br /> [ 108.070502][ T14] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> [ 108.123672][ T14] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250221-8.fc42 02/21/2025<br /> [ 108.127458][ T14] Workqueue: iou_exit io_ring_exit_work<br /> [ 108.174205][ T14] Call trace:<br /> [ 108.175649][ T14] sanity_check_pinned_pages+0x7cc/0x7d0 (P)<br /> [ 108.178138][ T14] unpin_user_page+0x80/0x10c<br /> [ 108.180189][ T14] io_release_ubuf+0x84/0xf8<br /> [ 108.182196][ T14] io_free_rsrc_node+0x250/0x57c<br /> [ 108.184345][ T14] io_rsrc_data_free+0x148/0x298<br /> [ 108.186493][ T14] io_sqe_buffers_unregister+0x84/0xa0<br /> [ 108.188991][ T14] io_ring_ctx_free+0x48/0x480<br /> [ 108.191057][ T14] io_ring_exit_work+0x764/0x7d8<br /> [ 108.193207][ T14] process_one_work+0x7e8/0x155c<br /> [ 108.195431][ T14] worker_thread+0x958/0xed8<br /> [ 108.197561][ T14] kthread+0x5fc/0x75c<br /> [ 108.199362][ T14] ret_from_fork+0x10/0x20<br /> <br /> We can pin a tail page of a folio, but then io_uring will try to unpin<br /> the head page of the folio. While it should be fine in terms of keeping<br /> the page actually alive, mm folks say it&amp;#39;s wrong and triggers a debug<br /> warning. Use unpin_user_folio() instead of unpin_user_page*.<br /> <br /> [axboe: adapt to current tree, massage commit message]
Severity CVSS v4.0: Pending analysis
Last modification:
09/07/2025

CVE-2025-38257

Publication date:
09/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/pkey: Prevent overflow in size calculation for memdup_user()<br /> <br /> Number of apqn target list entries contained in &amp;#39;nr_apqns&amp;#39; variable is<br /> determined by userspace via an ioctl call so the result of the product in<br /> calculation of size passed to memdup_user() may overflow.<br /> <br /> In this case the actual size of the allocated area and the value<br /> describing it won&amp;#39;t be in sync leading to various types of unpredictable<br /> behaviour later.<br /> <br /> Use a proper memdup_array_user() helper which returns an error if an<br /> overflow is detected. Note that it is different from when nr_apqns is<br /> initially zero - that case is considered valid and should be handled in<br /> subsequent pkey_handler implementations.<br /> <br /> Found by Linux Verification Center (linuxtesting.org).
Severity CVSS v4.0: Pending analysis
Last modification:
09/07/2025

CVE-2025-38241

Publication date:
09/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/shmem, swap: fix softlockup with mTHP swapin<br /> <br /> Following softlockup can be easily reproduced on my test machine with:<br /> <br /> echo always &gt; /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled<br /> swapon /dev/zram0 # zram0 is a 48G swap device<br /> mkdir -p /sys/fs/cgroup/memory/test<br /> echo 1G &gt; /sys/fs/cgroup/test/memory.max<br /> echo $BASHPID &gt; /sys/fs/cgroup/test/cgroup.procs<br /> while true; do<br /> dd if=/dev/zero of=/tmp/test.img bs=1M count=5120<br /> cat /tmp/test.img &gt; /dev/null<br /> rm /tmp/test.img<br /> done<br /> <br /> Then after a while:<br /> watchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787]<br /> Modules linked in: zram virtiofs<br /> CPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G L 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)·<br /> Tainted: [L]=SOFTLOCKUP<br /> Hardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015<br /> RIP: 0010:mpol_shared_policy_lookup+0xd/0x70<br /> Code: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8<br /> RSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202<br /> RAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001<br /> RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518<br /> RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001<br /> R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000<br /> FS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> shmem_alloc_folio+0x31/0xc0<br /> shmem_swapin_folio+0x309/0xcf0<br /> ? filemap_get_entry+0x117/0x1e0<br /> ? xas_load+0xd/0xb0<br /> ? filemap_get_entry+0x101/0x1e0<br /> shmem_get_folio_gfp+0x2ed/0x5b0<br /> shmem_file_read_iter+0x7f/0x2e0<br /> vfs_read+0x252/0x330<br /> ksys_read+0x68/0xf0<br /> do_syscall_64+0x4c/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f03f9a46991<br /> Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec<br /> RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991<br /> RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003<br /> RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380<br /> R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000<br /> R13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000<br /> <br /> <br /> The reason is simple, readahead brought some order 0 folio in swap cache,<br /> and the swapin mTHP folio being allocated is in conflict with it, so<br /> swapcache_prepare fails and causes shmem_swap_alloc_folio to return<br /> -EEXIST, and shmem simply retries again and again causing this loop.<br /> <br /> Fix it by applying a similar fix for anon mTHP swapin.<br /> <br /> The performance change is very slight, time of swapin 10g zero folios<br /> with shmem (test for 12 times):<br /> Before: 2.47s<br /> After: 2.48s<br /> <br /> [kasong@tencent.com: add comment]
Severity CVSS v4.0: Pending analysis
Last modification:
09/07/2025

CVE-2025-38242

Publication date:
09/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: userfaultfd: fix race of userfaultfd_move and swap cache<br /> <br /> This commit fixes two kinds of races, they may have different results:<br /> <br /> Barry reported a BUG_ON in commit c50f8e6053b0, we may see the same<br /> BUG_ON if the filemap lookup returned NULL and folio is added to swap<br /> cache after that.<br /> <br /> If another kind of race is triggered (folio changed after lookup) we<br /> may see RSS counter is corrupted:<br /> <br /> [ 406.893936] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0<br /> type:MM_ANONPAGES val:-1<br /> [ 406.894071] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0<br /> type:MM_SHMEMPAGES val:1<br /> <br /> Because the folio is being accounted to the wrong VMA.<br /> <br /> I&amp;#39;m not sure if there will be any data corruption though, seems no. <br /> The issues above are critical already.<br /> <br /> <br /> On seeing a swap entry PTE, userfaultfd_move does a lockless swap cache<br /> lookup, and tries to move the found folio to the faulting vma. Currently,<br /> it relies on checking the PTE value to ensure that the moved folio still<br /> belongs to the src swap entry and that no new folio has been added to the<br /> swap cache, which turns out to be unreliable.<br /> <br /> While working and reviewing the swap table series with Barry, following<br /> existing races are observed and reproduced [1]:<br /> <br /> In the example below, move_pages_pte is moving src_pte to dst_pte, where<br /> src_pte is a swap entry PTE holding swap entry S1, and S1 is not in the<br /> swap cache:<br /> <br /> CPU1 CPU2<br /> userfaultfd_move<br /> move_pages_pte()<br /> entry = pte_to_swp_entry(orig_src_pte);<br /> // Here it got entry = S1<br /> ... ...<br /> <br /> // folio A is a new allocated folio<br /> // and get installed into src_pte<br /> <br /> // src_pte now points to folio A, S1<br /> // has swap count == 0, it can be freed<br /> // by folio_swap_swap or swap<br /> // allocator&amp;#39;s reclaim.<br /> <br /> // folio B is a folio in another VMA.<br /> <br /> // S1 is freed, folio B can use it<br /> // for swap out with no problem.<br /> ...<br /> folio = filemap_get_folio(S1)<br /> // Got folio B here !!!<br /> ... ...<br /> <br /> // Now S1 is free to be used again.<br /> <br /> // Now src_pte is a swap entry PTE<br /> // holding S1 again.<br /> folio_trylock(folio)<br /> move_swap_pte<br /> double_pt_lock<br /> is_pte_pages_stable<br /> // Check passed because src_pte == S1<br /> folio_move_anon_rmap(...)<br /> // Moved invalid folio B here !!!<br /> <br /> The race window is very short and requires multiple collisions of multiple<br /> rare events, so it&amp;#39;s very unlikely to happen, but with a deliberately<br /> constructed reproducer and increased time window, it can be reproduced<br /> easily.<br /> <br /> This can be fixed by checking if the folio returned by filemap is the<br /> valid swap cache folio after acquiring the folio lock.<br /> <br /> Another similar race is possible: filemap_get_folio may return NULL, but<br /> folio (A) could be swapped in and then swapped out again using the same<br /> swap entry after the lookup. In such a case, folio (A) may remain in the<br /> swap cache, so it must be moved too:<br /> <br /> CPU1 CPU2<br /> userfaultfd_move<br /> move_pages_pte()<br /> entry = pte_to_swp_entry(orig_src_pte);<br /> // Here it got entry = S1, and S1 is not in swap cache<br /> folio = filemap_get<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
09/07/2025

CVE-2025-38243

Publication date:
09/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix invalid inode pointer dereferences during log replay<br /> <br /> In a few places where we call read_one_inode(), if we get a NULL pointer<br /> we end up jumping into an error path, or fallthrough in case of<br /> __add_inode_ref(), where we then do something like this:<br /> <br /> iput(&amp;inode-&gt;vfs_inode);<br /> <br /> which results in an invalid inode pointer that triggers an invalid memory<br /> access, resulting in a crash.<br /> <br /> Fix this by making sure we don&amp;#39;t do such dereferences.
Severity CVSS v4.0: Pending analysis
Last modification:
09/07/2025