It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2023-132 advisory.

    It has been discovered that on some AMD CPUs, the RAS (Return Address Stack, also called RAP - Return     Address Predictor - in some AMD documentation, and RSB - Return Stack Buffer - in Intel terminology) is     dynamically partitioned between non-idle threads.  This allows an attacker to control speculative     execution on the adjacent thread. (CVE-2022-27672)

    In the Linux kernel, the following vulnerability has been resolved:

    ovl: Use buf flexible array for memcpy() destination (CVE-2022-49743)

    In the Linux kernel, the following vulnerability has been resolved:

    mm/uffd: fix pte marker when fork() without fork event (CVE-2022-49744)

    The upstream bug report describes this issue as follows:

    A flaw found in the Linux Kernel in RDS (Reliable Datagram Sockets) protocol. The     rds_rm_zerocopy_callback() uses list_entry() on the head of a list causing a type confusion. Local user     can trigger this with rds_message_put(). Type confusion leads to `struct rds_msg_zcopy_info *info`     actually points to something else that is potentially controlled by local user. It is known how to trigger     this, which causes an OOB access, and a lock corruption. (CVE-2023-1078)

    A flaw was found in the Framebuffer Console (fbcon) in the Linux Kernel. When providing a font->width and     font->height greater than 32 to the fbcon_set_font, since there are no checks in place, a shift-out-of-     bounds occurs, leading to undefined behavior and possible denial of service. (CVE-2023-3161)

    brcm_nvram_parse in drivers/nvmem/brcm_nvram.c lacks check of the return value of kzalloc() and will cause     the NULL Pointer Dereference (CVE-2023-3359)

    A use-after-free flaw was found in vcs_read in drivers/tty/vt/vc_screen.c in vc_screen in the Linux     Kernel. In this flaw an attacker with local user access may lead to a system crash or a leak of internal     kernel information. (CVE-2023-3567)

    In the Linux kernel, the following vulnerability has been resolved:

    Fix page corruption caused by racy check in __free_pages (CVE-2023-52739)

    In the Linux kernel, the following vulnerability has been resolved:

    cifs: Fix use-after-free in rdata->read_into_pages() (CVE-2023-52741)

    In the Linux kernel, the following vulnerability has been resolved:

    xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr() (CVE-2023-52746)

    In the Linux kernel, the following vulnerability has been resolved:

    bpf: Skip invalid kfunc call in backtrack_insn (CVE-2023-52928)

    In the Linux kernel, the following vulnerability has been resolved:

    drm/i915: Fix potential bit_17 double-free (CVE-2023-52930)

    In the Linux kernel, the following vulnerability has been resolved:

    drm/i915: Avoid potential vm use-after-free (CVE-2023-52931)

    In the Linux kernel, the following vulnerability has been resolved:

    mm/swapfile: add cond_resched() in get_swap_pages() (CVE-2023-52932)

    In the Linux kernel, the following vulnerability has been resolved:

    Squashfs: fix handling and sanity checking of xattr_ids count (CVE-2023-52933)

    In the Linux kernel, the following vulnerability has been resolved:

    mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups (CVE-2023-52934)

    In the Linux kernel, the following vulnerability has been resolved:

    mm/khugepaged: fix ->anon_vma race (CVE-2023-52935)

    In the Linux kernel, the following vulnerability has been resolved:

    kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup() (CVE-2023-52936)

    In the Linux kernel, the following vulnerability has been resolved:

    HV: hv_balloon: fix memory leak with using debugfs_lookup() (CVE-2023-52937)

    In the Linux kernel, the following vulnerability has been resolved:

    mm: memcg: fix NULL pointer in mem_cgroup_track_foreign_dirty_slowpath() (CVE-2023-52939)

    In the Linux kernel, the following vulnerability has been resolved:

    mm: multi-gen LRU: fix crash during cgroup migration (CVE-2023-52940)

    In the Linux kernel, the following vulnerability has been resolved:

    cgroup/cpuset: Fix wrong check in update_parent_subparts_cpumask() (CVE-2023-52942)

    In the Linux kernel, the following vulnerability has been resolved:

    vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF (CVE-2023-52973)

    In the Linux kernel, the following vulnerability has been resolved:

    efi: fix potential NULL deref in efi_mem_reserve_persistent (CVE-2023-52976)

    In the Linux kernel, the following vulnerability has been resolved:

    net: openvswitch: fix flow memory leak in ovs_flow_cmd_new (CVE-2023-52977)

    In the Linux kernel, the following vulnerability has been resolved:

    squashfs: harden sanity check in squashfs_read_xattr_id_table (CVE-2023-52979)

    In the Linux kernel, the following vulnerability has been resolved:

    drm/i915: Fix request ref counting during error capture & debugfs dump (CVE-2023-52981)

    In the Linux kernel, the following vulnerability has been resolved:

    fscache: Use wait_on_bit() to wait for the freeing of relinquished volume (CVE-2023-52982)

    In the Linux kernel, the following vulnerability has been resolved:

    block, bfq: fix uaf for bfqq in bic_set_bfqq() (CVE-2023-52983)

    In the Linux kernel, the following vulnerability has been resolved:

    bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener (CVE-2023-52986)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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 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, 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 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() 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 (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 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--- (CVE-2023-52934)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
173140	Amazon Linux 2023 : bpftool, kernel, kernel-devel (ALAS2023-2023-132)	Nessus	Amazon Linux Local Security Checks	3/21/2023	2/24/2026	high
243861	Linux Distros Unpatched Vulnerability : CVE-2023-52934	Nessus	Misc.	8/5/2025	7/17/2026	medium

Detections

Analytics

Plugins Search

high

medium