Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2023-52923 State: PUBLISHED Published: 2025-01-20T10:48:13.723Z Last Updated: 2025-05-04T07:46:05.066Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: adapt set backend to use GC transaction API Use the GC transaction API to replace the old and buggy gc API and the busy mark approach. No set elements are removed from async garbage collection anymore, instead the _DEAD bit is set on so the set element is not visible from lookup path anymore. Async GC enqueues transaction work that might be aborted and retried later. rbtree and pipapo set backends does not set on the _DEAD bit from the sync GC pat
at might be aborted and retried later. rbtree and pipapo set backends does not set on the _DEAD bit from the sync GC path since this runs in control plane path where mutex is held. In this case, set elements are deactivated, removed and then released via RCU callback, sync GC never fails. References: - https://git.kernel.org/stable/c/cb4d00b563675ba8ff6ef94b077f58d816f68ba3 - https://git.kernel.org/stable/c/c357648929c8dff891502349769aafb8f0452bc2 - https://git.kernel.org/stable/c/146c76866795553dbc19998f36718d7986ad302b - https://git.kernel.org/stable/c/479a2cf5259347d6a1f658b0f791d27a34908e91 - https://git.kernel.org/stable/c/df650d6a4bf47248261b61ef6b174d7c54034d15 - https://git.kernel.or
658b0f791d27a34908e91 - https://git.kernel.org/stable/c/df650d6a4bf47248261b61ef6b174d7c54034d15 - https://git.kernel.org/stable/c/e4d71d6a9c7db93f7bf20c3a0f0659d63d7de681 - https://git.kernel.org/stable/c/f6c383b8c31a93752a52697f8430a71dcbc46adf
CVE ID: CVE-2023-52924 State: PUBLISHED Published: 2025-02-05T09:07:55.418Z Last Updated: 2025-05-04T07:46:06.745Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: don't skip expired elements during walk There is an asymmetry between commit/abort and preparation phase if the following conditions are met: 1. set is a verdict map ("1.2.3.4 : jump foo") 2. timeouts are enabled In this case, following sequence is problematic: 1. element E in set S refers to chain C 2. userspace requests removal of set S 3. kernel does a set walk to decrement chain->use count for all elements from preparation phase 4. kernel does
of set S 3. kernel does a set walk to decrement chain->use count for all elements from preparation phase 4. kernel does another set walk to remove elements from the commit phase (or another walk to do a chain->use increment for all elements from abort phase) If E has already expired in 1), it will be ignored during list walk, so its use count won't have been changed. Then, when set is culled, ->destroy callback will zap the element via nf_tables_set_elem_destroy(), but this function is only safe for elements that have been deactivated earlier from the preparation phase: lack of earlier deactivate removes the element but leaks the chain use count, which results in a WARN splat when the chain
ck of earlier deactivate removes the element but leaks the chain use count, which results in a WARN splat when the chain gets removed later, plus a leak of the nft_chain structure. Update pipapo_get() not to skip expired elements, otherwise flush command reports bogus ENOENT errors. References: - https://git.kernel.org/stable/c/94313a196b44184b5b52c1876da6a537701b425a - https://git.kernel.org/stable/c/1da4874d05da1526b11b82fc7f3c7ac38749ddf8 - https://git.kernel.org/stable/c/b15ea4017af82011dd55225ce77cce3d4dfc169c - https://git.kernel.org/stable/c/7c7e658a36f8b1522bd3586d8137e5f93a25ddc5 - https://git.kernel.org/stable/c/59dab3bf0b8fc08eb802721c0532f13dd89209b8 - https://git.kernel.org/stab
137e5f93a25ddc5 - https://git.kernel.org/stable/c/59dab3bf0b8fc08eb802721c0532f13dd89209b8 - https://git.kernel.org/stable/c/bd156ce9553dcaf2d6ee2c825d1a5a1718e86524 - https://git.kernel.org/stable/c/24138933b97b055d486e8064b4a1721702442a9b
CVE ID: CVE-2023-52925 State: PUBLISHED Published: 2025-02-05T09:07:56.434Z Last Updated: 2025-05-04T12:49:52.404Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: don't fail inserts if duplicate has expired nftables selftests fail: run-tests.sh testcases/sets/0044interval_overlap_0 Expected: 0-2 . 0-3, got: W: [FAILED] ./testcases/sets/0044interval_overlap_0: got 1 Insertion must ignore duplicate but expired entries. Moreover, there is a strange asymmetry in nft_pipapo_activate: It refetches the current element, whereas the other ->activate callbacks (bitmap, hash, rhash, rbtree) use elem->priv. Same for .r
es the current element, whereas the other ->activate callbacks (bitmap, hash, rhash, rbtree) use elem->priv. Same for .remove: other set implementations take elem->priv, nft_pipapo_remove fetches elem->priv, then does a relookup, remove this. I suspect this was the reason for the change that prompted the removal of the expired check in pipapo_get() in the first place, but skipping exired elements there makes no sense to me, this helper is used for normal get requests, insertions (duplicate check) and deactivate callback. In first two cases expired elements must be skipped. For ->deactivate(), this gets called for DELSETELEM, so it seems to me that expired elements should be skipped as well,
For ->deactivate(), this gets called for DELSETELEM, so it seems to me that expired elements should be skipped as well, i.e. delete request should fail with -ENOENT error. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/891ca5dfe3b718b441fc786014a7ba8f517da188 - https://git.kernel.org/stable/c/af78b0489e8898a8c9449ffc0fdd2e181916f0d4 - https://git.kernel.org/stable/c/59ee68c437c562170265194a99698c805a686bb3 - https://git.kernel.org/stable/c/156369a702c33ad5434a19c3a689bfb836d4e0b8 - https://git.kernel.org/stable/c/7845914f45f066497ac75b30c50dbc735e84e884
CVE ID: CVE-2023-52926 State: PUBLISHED Published: 2025-02-24T09:01:19.209Z Last Updated: 2025-11-03T20:36:19.914Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: IORING_OP_READ did not correctly consume the provided buffer list when read i/o returned < 0 (except for -EAGAIN and -EIOCBQUEUED return). This can lead to a potential use-after-free when the completion via io_rw_done runs at separate context. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/72060434a14caea20925e492310d6e680e3f9007 - https://git.kernel.org/stable/c/6c27fc6a783c8a77c756dd5461b15e46
org/stable/c/72060434a14caea20925e492310d6e680e3f9007 - https://git.kernel.org/stable/c/6c27fc6a783c8a77c756dd5461b15e465020d075 - https://git.kernel.org/stable/c/a08d195b586a217d76b42062f88f375a3eedda4d
CVE ID: CVE-2023-52927 State: PUBLISHED Published: 2025-03-14T14:25:59.166Z Last Updated: 2025-11-03T19:28:52.085Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: allow exp not to be removed in nf_ct_find_expectation Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches. This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl. Additional Analyst Notes: - CVE Program Container: Re
to be removed by setting IPS_CONFIRMED in the status of the tmpl. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/3fa58a6fbd1e9e5682d09cdafb08fba004cb12ec - https://git.kernel.org/stable/c/4914109a8e1e494c6aa9852f9e84ec77a5fc643f - https://seadragnol.github.io/posts/CVE-2023-52927/
CVE ID: CVE-2023-52928 State: PUBLISHED Published: 2025-03-27T16:37:10.471Z Last Updated: 2025-09-03T12:59:07.782Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Skip invalid kfunc call in backtrack_insn The verifier skips invalid kfunc call in check_kfunc_call(), which would be captured in fixup_kfunc_call() if such insn is not eliminated by dead code elimination. However, this can lead to the following warning in backtrack_insn(), also see [1]: ------------[ cut here ]------------ verifier backtracking bug WARNING: CPU: 6 PID: 8646 at kernel/bpf/verifier.c:2756 backtrack_insn kernel/bpf/verifier.c:2756 __mark_chain_preci
bug WARNING: CPU: 6 PID: 8646 at kernel/bpf/verifier.c:2756 backtrack_insn kernel/bpf/verifier.c:2756 __mark_chain_precision kernel/bpf/verifier.c:3065 mark_chain_precision kernel/bpf/verifier.c:3165 adjust_reg_min_max_vals kernel/bpf/verifier.c:10715 check_alu_op kernel/bpf/verifier.c:10928 do_check kernel/bpf/verifier.c:13821 [inline] do_check_common kernel/bpf/verifier.c:16289 [...] So make backtracking conservative with this by returning ENOTSUPP. [1] https://lore.kernel.org/bpf/CACkBjsaXNceR8ZjkLG=dT3P=4A8SBsg0Z5h5PWLryF5=ghKq=g@mail.gmail.com/ References: - https://git.kernel.org/stable/c/6e2fac197de2c4c041bdd8982cffb104689113f1 - https://git.kernel.org/stable/c/74eec8266f37aff609db6a2
t.kernel.org/stable/c/6e2fac197de2c4c041bdd8982cffb104689113f1 - https://git.kernel.org/stable/c/74eec8266f37aff609db6a2f2b093e56a11c28c4 - https://git.kernel.org/stable/c/d3178e8a434b58678d99257c0387810a24042fb6
CVE ID: CVE-2023-52929 State: PUBLISHED Published: 2025-03-27T16:37:11.396Z Last Updated: 2025-05-04T07:46:12.575Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix cleanup after dev_set_name() If dev_set_name() fails, we leak nvmem->wp_gpio as the cleanup does not put this. While a minimal fix for this would be to add the gpiod_put() call, we can do better if we split device_register(), and use the tested nvmem_release() cleanup code by initialising the device early, and putting the device. This results in a slightly larger fix, but results in clear code. Note: this patch depends on "nvmem: core: initialise nvmem
results in a slightly larger fix, but results in clear code. Note: this patch depends on "nvmem: core: initialise nvmem->id early" and "nvmem: core: remove nvmem_config wp_gpio". [Srini: Fixed subject line and error code handing with wp_gpio while applying.] References: - https://git.kernel.org/stable/c/23676ecd2eb377f7c24a6ff578b0f4c7135658b6 - https://git.kernel.org/stable/c/8f9c4b2a3b132bf6698e477aba6ee194b40c75f4 - https://git.kernel.org/stable/c/39708bc8da7858de0bed9b3a88b3beb1d1e0b443 - https://git.kernel.org/stable/c/560181d3ace61825f4ca9dd3481d6c0ee6709fa8
CVE ID: CVE-2023-52930 State: PUBLISHED Published: 2025-03-27T16:37:12.302Z Last Updated: 2025-10-01T19:26:36.577Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential bit_17 double-free A userspace with multiple threads racing I915_GEM_SET_TILING to set the tiling to I915_TILING_NONE could trigger a double free of the bit_17 bitmask. (Or conversely leak memory on the transition to tiled.) Move allocation/free'ing of the bitmask within the section protected by the obj lock. [tursulin: Correct fixes tag and added cc stable.] (cherry picked from commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e) Additional Analyst
fixes tag and added cc stable.] (cherry picked from commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e) Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b591abac78e25269b12e3d7170c99463f8c5cb02 - https://git.kernel.org/stable/c/e3ebc3e23bd9028a8a9a26cbc5985f99be445f65 - https://git.kernel.org/stable/c/0769f997a7b6d5cb8336db0b4ec3d2d311b8097c - https://git.kernel.org/stable/c/7057a8f126f14f14b040faecfa220fd27c6c2f85
CVE ID: CVE-2023-52931 State: PUBLISHED Published: 2025-03-27T16:37:12.969Z Last Updated: 2025-05-04T07:46:15.198Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/i915: Avoid potential vm use-after-free Adding the vm to the vm_xa table makes it visible to userspace, which could try to race with us to close the vm. So we need to take our extra reference before putting it in the table. (cherry picked from commit 99343c46d4e2b34c285d3d5f68ff04274c2f9fb4) Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/764accc2c1b8fd1507be2e7f436c94cdce887a00 - https://git.kernel.org/stable/c/41d4
ences: - https://git.kernel.org/stable/c/764accc2c1b8fd1507be2e7f436c94cdce887a00 - https://git.kernel.org/stable/c/41d419382ec7e257e54b7b6ff0d3623aafb1316d
CVE ID: CVE-2023-52932 State: PUBLISHED Published: 2025-03-27T16:37:13.594Z Last Updated: 2025-10-01T19:26:36.446Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: add cond_resched() in get_swap_pages() The softlockup still occurs in get_swap_pages() under memory pressure. 64 CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram device is 50MB with same priority as si. Use the stress-ng tool to increase memory pressure, causing the system to oom frequently. The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens of thousands of times to find available space (extreme case: cond_resc
safe() loops in get_swap_pages() could reach tens of thousands of times to find available space (extreme case: cond_resched() is not called in scan_swap_map_slots()). Let's add cond_resched() into get_swap_pages() when failed to find available space to avoid softlockup. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/29f0349c5c76b627fe06b87d4b13fa03a6ce8e64 - https://git.kernel.org/stable/c/387217b97e99699c34e6d95ce2b91b327fcd853e - https://git.kernel.org/stable/c/d49c85a1913385eed46dd16a25ad0928253767f0 - https://git.kernel.org/stable/c/30187be29052bba9203b0ae2bdd815e0bc2faaab - https://git.kernel.org/stable/c/5dbe1ebd56470d03b78fc31491a9e4d4
org/stable/c/30187be29052bba9203b0ae2bdd815e0bc2faaab - https://git.kernel.org/stable/c/5dbe1ebd56470d03b78fc31491a9e4d433106ef2 - https://git.kernel.org/stable/c/49178d4d61e78aed8c837dfeea8a450700f196e2 - https://git.kernel.org/stable/c/7717fc1a12f88701573f9ed897cc4f6699c661e3
CVE ID: CVE-2023-52933 State: PUBLISHED Published: 2025-03-27T16:37:14.230Z Last Updated: 2025-05-04T12:49:53.516Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Squashfs: fix handling and sanity checking of xattr_ids count A Sysbot [1] corrupted filesystem exposes two flaws in the handling and sanity checking of the xattr_ids count in the filesystem. Both of these flaws cause computation overflow due to incorrect typing. In the corrupted filesystem the xattr_ids value is 4294967071, which stored in a signed variable becomes the negative number -225. Flaw 1 (64-bit systems only): The signed integer xattr_ids variable causes sig
ariable becomes the negative number -225. Flaw 1 (64-bit systems only): The signed integer xattr_ids variable causes sign extension. This causes variable overflow in the SQUASHFS_XATTR_*(A) macros. The variable is first multiplied by sizeof(struct squashfs_xattr_id) where the type of the sizeof operator is "unsigned long". On a 64-bit system this is 64-bits in size, and causes the negative number to be sign extended and widened to 64-bits and then become unsigned. This produces the very large number 18446744073709548016 or 2^64 - 3600. This number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0 (stored in l
S_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0 (stored in len). Flaw 2 (32-bit systems only): On a 32-bit system the integer variable is not widened by the unsigned long type of the sizeof operator (32-bits), and the signedness of the variable has no effect due it always being treated as unsigned. The above corrupted xattr_ids value of 4294967071, when multiplied overflows and produces the number 4294963696 or 2^32 - 3400. This number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows again and produces a length of 0. The effect of the 0 length computation: In conjunction with
FS_METADATA_SIZE overflows again and produces a length of 0. The effect of the 0 length computation: In conjunction with the corrupted xattr_ids field, the filesystem also has a corrupted xattr_table_start value, where it matches the end of filesystem value of 850. This causes the following sanity check code to fail because the incorrectly computed len of 0 matches the incorrect size of the table reported by the superblock (0 bytes). len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids); indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids); /* * The computed size of the index table (len bytes) should exactly * match the table start and end points */ start = table_start + sizeof(*id_table); end = msblk->bytes_
s) should exactly * match the table start and end points */ start = table_start + sizeof(*id_table); end = msblk->bytes_used; if (len != (end - start)) return ERR_PTR(-EINVAL); Changing the xattr_ids variable to be "usigned int" fixes the flaw on a 64-bit system. This relies on the fact the computation is widened by the unsigned long type of the sizeof operator. Casting the variable to u64 in the above macro fixes this flaw on a 32-bit system. It also means 64-bit systems do not implicitly rely on the type of the sizeof operator to widen the computation. [1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/ References: - https://git.kernel.org/stable/c/7fe583c9bec10cd4b76
rnel.org/lkml/000000000000cd44f005f1a0f17f@google.com/ References: - https://git.kernel.org/stable/c/7fe583c9bec10cd4b76231c51b37f3e4ca646e01 - https://git.kernel.org/stable/c/b38c3e9e0adc01956cc3e5a52e4d3f92f79d88e2 - https://git.kernel.org/stable/c/1369322c1de52c7b9b988b95c9903110a4566778 - https://git.kernel.org/stable/c/5c4d4a83bf1a862d80c1efff1c6e3ce33b501e2e - https://git.kernel.org/stable/c/997bed0f3cde78a3e639d624985bf4a95cf767e6 - https://git.kernel.org/stable/c/a7da7d01ac5ce9b369a1ac70e1197999cc6c9686 - https://git.kernel.org/stable/c/f65c4bbbd682b0877b669828b4e033b8d5d0a2dc
CVE ID: CVE-2023-52934 State: PUBLISHED Published: 2025-03-27T16:37:14.857Z Last Updated: 2025-05-04T07:46:19.066Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups In commit 34488399fa08 ("mm/madvise: add file and shmem support to MADV_COLLAPSE") we make the following change to find_pmd_or_thp_or_none(): - if (!pmd_present(pmde)) - return SCAN_PMD_NULL; + if (pmd_none(pmde)) + return SCAN_PMD_NONE; This was for-use by MADV_COLLAPSE file/shmem codepaths, where MADV_COLLAPSE might identify a pte-mapped hugepage, only to have khugepaged race-in, free the pte table, and clear the p
MADV_COLLAPSE might identify a pte-mapped hugepage, only to have khugepaged race-in, free the pte table, and clear the pmd. Such codepaths include: A) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER already in the pagecache. B) In retract_page_tables(), if we fail to grab mmap_lock for the target mm/address. In these cases, collapse_pte_mapped_thp() really does expect a none (not just !present) pmd, and we want to suitably identify that case separate from the case where no pmd is found, or it's a bad-pmd (of course, many things could happen once we drop mmap_lock, and the pmd could plausibly undergo multiple transitions due to intervening fault, split, etc). Regardless,
mmap_lock, and the pmd could plausibly undergo multiple transitions due to intervening fault, split, etc). Regardless, the code is prepared install a huge-pmd only when the existing pmd entry is either a genuine pte-table-mapping-pmd, or the none-pmd. However, the commit introduces a logical hole; namely, that we've allowed !none- && !huge- && !bad-pmds to be classified as genuine pte-table-mapping-pmds. One such example that could leak through are swap entries. The pmd values aren't checked again before use in pte_offset_map_lock(), which is expecting nothing less than a genuine pte-table-mapping-pmd. We want to put back the !pmd_present() check (below the pmd_none() check), but need to be
genuine pte-table-mapping-pmd. We want to put back the !pmd_present() check (below the pmd_none() check), but need to be careful to deal with subtleties in pmd transitions and treatments by various arch. The issue is that __split_huge_pmd_locked() temporarily clears the present bit (or otherwise marks the entry as invalid), but pmd_present() and pmd_trans_huge() still need to return true while the pmd is in this transitory state. For example, x86's pmd_present() also checks the _PAGE_PSE , riscv's version also checks the _PAGE_LEAF bit, and arm64 also checks a PMD_PRESENT_INVALID bit. Covering all 4 cases for x86 (all checks done on the same pmd value): 1) pmd_present() && pmd_trans_huge() A
NVALID bit. Covering all 4 cases for x86 (all checks done on the same pmd value): 1) pmd_present() && pmd_trans_huge() All we actually know here is that the PSE bit is set. Either: a) We aren't racing with __split_huge_page(), and PRESENT or PROTNONE is set. => huge-pmd b) We are currently racing with __split_huge_page(). The danger here is that we proceed as-if we have a huge-pmd, but really we are looking at a pte-mapping-pmd. So, what is the risk of this danger? The only relevant path is: madvise_collapse() -> collapse_pte_mapped_thp() Where we might just incorrectly report back "success", when really the memory isn't pmd-backed. This is fine, since split could happen immediately after (a
ort back "success", when really the memory isn't pmd-backed. This is fine, since split could happen immediately after (actually) successful madvise_collapse(). So, it should be safe to just assume huge-pmd here. 2) pmd_present() && !pmd_trans_huge() Either: a) PSE not set and either PRESENT or PROTNONE is. => pte-table-mapping pmd (or PROT_NONE) b) devmap. This routine can be called immediately after unlocking/locking mmap_lock -- or called with no locks held (see khugepaged_scan_mm_slot()), so previous VMA checks have since been invalidated. 3) !pmd_present() && pmd_trans_huge() Not possible. 4) !pmd_present() && !pmd_trans_huge() Neither PRESENT nor PROTNONE set => not present I've checked
huge() Not possible. 4) !pmd_present() && !pmd_trans_huge() Neither PRESENT nor PROTNONE set => not present I've checked all archs that implement pmd_trans_huge() (arm64, riscv, powerpc, longarch, x86, mips, s390) and this logic roughly translates (though devmap treatment is unique to x86 and powerpc, and (3) doesn't necessarily hold in general -- but that doesn't matter since !pmd_present() always takes failure path). Also, add a comment above find_pmd_or_thp_or_none() ---truncated--- References: - https://git.kernel.org/stable/c/96aaaf8666010a39430cecf8a65c7ce2908a030f - https://git.kernel.org/stable/c/edb5d0cf5525357652aff6eacd9850b8ced07143
CVE ID: CVE-2023-52935 State: PUBLISHED Published: 2025-03-27T16:37:15.505Z Last Updated: 2025-11-03T17:31:05.059Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: fix ->anon_vma race If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires it to be locked. Page table traversal is allowed under any one of the mmap lock, the anon_vma lock (if the VMA is associated with an anon_vma), and the mapping lock (if the VMA is associated with a mapping); and so to be able to remove page tables, we must hold all three of them. retract_page_tables() bails out if an ->anon_vma is attached, but does this check b