MiracleLinux 8 : kernel-4.18.0-553.143.1.el8_10 (AXSA:2026-1337:51)

#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
#
# The package checks in this plugin were extracted from
# Miracle Linux Security Advisory AXSA:2026-1337:51.
##

include('compat.inc');

if (description)
{
  script_id(329196);
  script_version("1.1");
  script_set_attribute(attribute:"plugin_modification_date", value:"2026/07/23");

  script_cve_id(
    "CVE-2025-71066",
    "CVE-2025-71089",
    "CVE-2026-31411",
    "CVE-2026-43499",
    "CVE-2026-46113",
    "CVE-2026-53266",
    "CVE-2026-53359"
  );

  script_name(english:"MiracleLinux 8 : kernel-4.18.0-553.143.1.el8_10 (AXSA:2026-1337:51)");

  script_set_attribute(attribute:"synopsis", value:
"The remote MiracleLinux host is missing one or more security updates.");
  script_set_attribute(attribute:"description", value:
"The remote MiracleLinux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the
AXSA:2026-1337:51 advisory.

    Please update
    CVE-2025-71066
    In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: Always remove class
    from active list before deleting in ets_qdisc_change [email protected] says: The
    vulnerability is a race condition between `ets_qdisc_dequeue` and `ets_qdisc_change`. It leads to UAF on
    `struct Qdisc` object. Attacker requires the capability to create new user and network namespace in order
    to trigger the bug. See my additional commentary at the end of the analysis. Analysis: static int
    ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt, struct netlink_ext_ack *extack) { ... // (1) this
    lock is preventing .change handler (`ets_qdisc_change`) //to race with .dequeue handler
    (`ets_qdisc_dequeue`) sch_tree_lock(sch); for (i = nbands; i < oldbands; i++) { if (i >= q->nstrict &&
    q->classes[i].qdisc->q.qlen) list_del_init(&q->classes[i].alist); qdisc_purge_queue(q->classes[i].qdisc);
    } WRITE_ONCE(q->nbands, nbands); for (i = nstrict; i < q->nstrict; i++) { if (q->classes[i].qdisc->q.qlen)
    { // (2) the class is added to the q->active list_add_tail(&q->classes[i].alist, &q->active);
    q->classes[i].deficit = quanta[i]; } } WRITE_ONCE(q->nstrict, nstrict); memcpy(q->prio2band, priomap,
    sizeof(priomap)); for (i = 0; i < q->nbands; i++) WRITE_ONCE(q->classes[i].quantum, quanta[i]); for (i =
    oldbands; i < q->nbands; i++) { q->classes[i].qdisc = queues[i]; if (q->classes[i].qdisc != &noop_qdisc)
    qdisc_hash_add(q->classes[i].qdisc, true); } // (3) the qdisc is unlocked, now dequeue can be called in
    parallel // to the rest of .change handler sch_tree_unlock(sch); ets_offload_change(sch); for (i =
    q->nbands; i < oldbands; i++) { // (4) we're reducing the refcount for our class's qdisc and // freeing it
    qdisc_put(q->classes[i].qdisc); // (5) If we call .dequeue between (4) and (5), we will have // a strong
    UAF and we can control RIP q->classes[i].qdisc = NULL; WRITE_ONCE(q->classes[i].quantum, 0);
    q->classes[i].deficit = 0; gnet_stats_basic_sync_init(&q->classes[i].bstats);
    memset(&q->classes[i].qstats, 0, sizeof(q->classes[i].qstats)); } return 0; } Comment: This happens
    because some of the classes have their qdiscs assigned to NULL, but remain in the active list. This commit
    fixes this issue by always removing the class from the active list before deleting and freeing its
    associated qdisc Reproducer Steps (trimmed version of what was sent by [email protected]) ```
    DEV=${DEV:-lo} ROOT_HANDLE=${ROOT_HANDLE:-1:} BAND2_HANDLE=${BAND2_HANDLE:-20:} # child under 1:2
    PING_BYTES=${PING_BYTES:-48} PING_COUNT=${PING_COUNT:-200000} PING_DST=${PING_DST:-127.0.0.1}
    SLOW_TBF_RATE=${SLOW_TBF_RATE:-8bit} SLOW_TBF_BURST=${SLOW_TBF_BURST:-100b}
    SLOW_TBF_LAT=${SLOW_TBF_LAT:-1s} cleanup() { tc qdisc del dev $DEV root 2>/dev/null } trap cleanup
    EXIT ip link set $DEV up tc qdisc del dev $DEV root 2>/dev/null || true tc qdisc add dev $DEV root
    handle $ROOT_HANDLE ets bands 2 strict 2 tc qdisc add dev $DEV parent 1:2 handle $BAND2_HANDLE \ tbf
    rate $SLOW_TBF_RATE burst $SLOW_TBF_BURST latency $SLOW_TBF_LAT tc filter add dev $DEV parent 1:
    protocol all prio 1 u32 match u32 0 0 flowid 1:2 tc -s qdisc ls dev $DEV ping -I $DEV -f -c
    $PING_COUNT -s $PING_BYTES -W 0.001 $PING_DST \ >/dev/null 2>&1 & tc qdisc change dev $DEV root
    handle $ROOT_HANDLE ets bands 2 strict 0 tc qdisc change dev $DEV root handle $ROOT_HANDLE ets bands
    2 strict 2 tc -s qdisc ls dev $DEV tc qdisc del dev $DEV parent ---truncated---
    CVE-2025-71089
    In the Linux kernel, the following vulnerability has been resolved: iommu: disable SVA when CONFIG_X86 is
    set Patch series Fix stale IOTLB entries for kernel address space, v7. This proposes a fix for a
    security vulnerability related to IOMMU Shared Virtual Addressing (SVA). In an SVA context, an IOMMU can
    cache kernel page table entries. When a kernel page table page is freed and reallocated for another
    purpose, the IOMMU might still hold stale, incorrect entries. This can be exploited to cause a use-after-
    free or write-after-free condition, potentially leading to privilege escalation or data corruption. This
    solution introduces a deferred freeing mechanism for kernel page table pages, which provides a safe window
    to notify the IOMMU to invalidate its caches before the page is reused. This patch (of 8): In the IOMMU
    Shared Virtual Addressing (SVA) context, the IOMMU hardware shares and walks the CPU's page tables. The
    x86 architecture maps the kernel's virtual address space into the upper portion of every process's page
    table. Consequently, in an SVA context, the IOMMU hardware can walk and cache kernel page table entries.
    The Linux kernel currently lacks a notification mechanism for kernel page table changes, specifically when
    page table pages are freed and reused. The IOMMU driver is only notified of changes to user virtual
    address mappings. This can cause the IOMMU's internal caches to retain stale entries for kernel VA. Use-
    After-Free (UAF) and Write-After-Free (WAF) conditions arise when kernel page table pages are freed and
    later reallocated. The IOMMU could misinterpret the new data as valid page table entries. The IOMMU might
    then walk into attacker-controlled memory, leading to arbitrary physical memory DMA access or privilege
    escalation. This is also a Write-After-Free issue, as the IOMMU will potentially continue to write
    Accessed and Dirty bits to the freed memory while attempting to walk the stale page tables. Currently, SVA
    contexts are unprivileged and cannot access kernel mappings. However, the IOMMU will still walk kernel-
    only page tables all the way down to the leaf entries, where it realizes the mapping is for the kernel and
    errors out. This means the IOMMU still caches these intermediate page table entries, making the described
    vulnerability a real concern. Disable SVA on x86 architecture until the IOMMU can receive notification to
    flush the paging cache before freeing the CPU kernel page table pages.
    CVE-2026-31411
    In the Linux kernel, the following vulnerability has been resolved: net: atm: fix crash due to unvalidated
    vcc pointer in sigd_send() Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg ->
    sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer
    comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM,
    0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... };
    *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences
    0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq()
    when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same
    pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by
    introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how
    sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct
    atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using
    sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a
    race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after
    find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only
    affects the logical state, not memory safety. [1]:
    https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3
    CVE-2026-43499
    In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of
    current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-
    lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case
    waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That
    results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the
    waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around.
    3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of
    current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup
    rt_mutex_adjust_prio_chain(), add a comment and amend the changelog ]
    CVE-2026-46113
    In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-
    free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the
    SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM
    entries (similar to commit aad885e77496, KVM: x86/mmu: Drop/zap existing present SPTE even when creating
    an MMIO SPTE, 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in
    that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked
    by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the
    PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM
    installs a new leaf SPTE and rmap entry; the SPTE uses the correct GFN (i.e. based on the new mapping,
    as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore
    the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the
    first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However,
    rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find
    the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page
    accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty
    logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's
    walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then
    the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if
    KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response
    to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the
    GFN matches and walks into the wrong shadow page. However, that was only an imprecision until
    2032a93d66fa (KVM: MMU: Don't allocate gfns page for direct mmu pages) came along. Fix it by checking
    for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone,
    KVM installs the rmap in the right location, and everyone is happy.
    CVE-2026-53166
    REJECTED
    CVE-2026-53266
    In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP
    rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind
    skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is
    addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking
    skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would
    reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender
    hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to
    skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only
    safely reads the ARP header; it does not make the later sender hardware address range writable. If that
    range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits()
    maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable
    before reading the ARP header and before calling skb_store_bits().
    CVE-2026-53359
    In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-
    free due to unexpected role Commit 0cb2af2ea66ad (KVM: x86: Fix shadow paging use-after-free due to
    unexpected GFN) fixed a shadow paging mismatch between stored and computed GFNs; the bug could be
    triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove()
    call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the
    GFN of the struct kvm_mmu_page. A similar hole however remains if the modified PDE points to a non-leaf
    page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page
    creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However,
    kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page. The next step is
    installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the
    walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn()
    computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or
    sp->gfns[] in older kernels). It therefore fails to remove the recorded entry. When the memslot is dropped
    the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that
    later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies
    in the freed page, causing the use-after-free.

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

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version
number.");
  script_set_attribute(attribute:"see_also", value:"https://tsn.miraclelinux.com/en/node/24162");
  script_set_attribute(attribute:"solution", value:
"Update the affected packages.");
  script_set_cvss_base_vector("CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C");
  script_set_cvss_temporal_vector("CVSS2#E:POC/RL:OF/RC:C");
  script_set_cvss3_base_vector("CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H");
  script_set_cvss3_temporal_vector("CVSS:3.0/E:P/RL:O/RC:C");
  script_set_attribute(attribute:"cvss_score_source", value:"CVE-2025-71089");

  script_set_attribute(attribute:"exploitability_ease", value:"Exploits are available");
  script_set_attribute(attribute:"exploit_available", value:"true");
  script_set_attribute(attribute:"vendor_severity", value:"High");

  script_set_attribute(attribute:"vuln_publication_date", value:"2026/01/13");
  script_set_attribute(attribute:"patch_publication_date", value:"2026/07/23");
  script_set_attribute(attribute:"plugin_publication_date", value:"2026/07/23");

  script_set_attribute(attribute:"plugin_type", value:"local");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:bpftool");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-abi-stablelists");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-core");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-cross-headers");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-debug");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-debug-core");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-debug-devel");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-debug-modules");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-debug-modules-extra");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-devel");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-headers");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-modules");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-modules-extra");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-tools");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-tools-libs");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:kernel-tools-libs-devel");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:perf");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:miracle:linux:python3-perf");
  script_set_attribute(attribute:"cpe", value:"cpe:/o:miracle:linux:8");
  script_set_attribute(attribute:"generated_plugin", value:"current");
  script_end_attributes();

  script_category(ACT_GATHER_INFO);
  script_family(english:"Miracle Linux Local Security Checks");

  script_copyright(english:"This script is Copyright (C) 2026 and is owned by Tenable, Inc. or an Affiliate thereof.");

  script_dependencies("ssh_get_info.nasl");
  script_require_keys("Host/local_checks_enabled", "Host/MiracleLinux/release", "Host/MiracleLinux/rpm-list", "Host/cpu");

  exit(0);
}


include('rpm2.inc');

if (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);
var os_product = get_kb_item('installed_os/local/SSH/0/product');
if (isnull(os_product) || 'MIRACLE LINUX' >!< os_product) audit(AUDIT_OS_NOT, 'MIRACLE LINUX');
var os_version = get_kb_item('installed_os/local/SSH/0/version');
if (isnull(os_version)) audit(AUDIT_UNKNOWN_APP_VER, 'MIRACLE LINUX');
if (! preg(pattern:"^8([^0-9]|$)", string:os_version)) audit(AUDIT_OS_NOT, 'MiracleLinux 8.x', 'MIRACLE LINUX ' + os_version);

if (!get_kb_item('Host/MiracleLinux/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);

var cpu = get_kb_item('Host/cpu');
if (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);
if ('aarch64' >!< cpu && 'ppc' >!< cpu && 's390' >!< cpu && 'x86_64' >!< cpu && cpu !~ "^i[3-6]86$") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'MIRACLE LINUX', cpu);

var constraints = [
  {
    'release': '8',
    'pkgs': [
      {'reference':'bpftool-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-abi-stablelists-4.18.0-553.143.1.el8_10', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-core-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-cross-headers-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-debug-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-debug-core-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-debug-devel-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-debug-modules-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-debug-modules-extra-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-devel-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-headers-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-modules-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-modules-extra-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-tools-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-tools-libs-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'kernel-tools-libs-devel-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'perf-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'},
      {'reference':'python3-perf-4.18.0-553.143.1.el8_10', 'cpu':'x86_64', 'el_string':'el8_10', 'rpm_spec_vers_cmp':TRUE, 'epoch':'0'}
    ]
  }
];

var os_release = get_one_kb_item('installed_os/local/SSH/0/release');
var os_sp = get_one_kb_item('Host/*/minor_release');

var flag = 0;
var reference;
var sp;
var _cpu;
var el_string;
var rpm_spec_vers_cmp;
var epoch;
var allowmaj;
var exists_check;
var cves;
foreach var constraint ( constraints ) {
  # Check that the target release is equal to the affected release
  if (!empty_or_null(constraint['release'])){
    if (constraint['release'] != os_release) continue;
  }
  if (!empty_or_null(constraint['sp'])){
    if (constraint['sp'] != os_sp) continue;
  }
  foreach var pkg ( constraint['pkgs'] ) {
    reference = NULL;
    sp = NULL;
    _cpu = NULL;
    el_string = NULL;
    rpm_spec_vers_cmp = NULL;
    epoch = NULL;
    allowmaj = NULL;
    exists_check = NULL;
    cves = NULL;
    if (!empty_or_null(pkg['reference'])) reference = pkg['reference'];
    if (!empty_or_null(pkg['sp'])) sp = pkg['sp'];
    if (!empty_or_null(pkg['cpu'])) _cpu = pkg['cpu'];
    if (!empty_or_null(pkg['el_string'])) el_string = pkg['el_string'];
    if (!empty_or_null(pkg['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = pkg['rpm_spec_vers_cmp'];
    if (!empty_or_null(pkg['epoch'])) epoch = pkg['epoch'];
    if (!empty_or_null(pkg['allowmaj'])) allowmaj = pkg['allowmaj'];
    if (!empty_or_null(pkg['exists_check'])) exists_check = pkg['exists_check'];
    if (!empty_or_null(pkg['cves'])) cves = pkg['cves'];
    if (reference &&
        ## (no known rpm to check OR known rpm_exists)
        (!exists_check || rpm_exists(rpm:exists_check)) &&
        rpm_check(sp:sp, cpu:_cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj, cves:cves)) flag++;
  }
}
if (flag)
{
  security_report_v4(
      port       : 0,
      severity   : SECURITY_WARNING,
      extra      : rpm_report_get()
  );
  exit(0);
}
else
{
  var tested = pkg_tests_get();
  if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);
  else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'bpftool / kernel / kernel-abi-stablelists / kernel-core / etc');
}