CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1782148320)

#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
##

include('compat.inc');

if (description)
{
  script_id(353232);
  script_version("1.1");
  script_set_attribute(attribute:"plugin_modification_date", value:"2026/09/30");

  script_cve_id(
    "CVE-2021-47288",
    "CVE-2022-48790",
    "CVE-2022-48791",
    "CVE-2022-49006",
    "CVE-2022-49674",
    "CVE-2022-49842",
    "CVE-2022-50021",
    "CVE-2022-50093",
    "CVE-2022-50200",
    "CVE-2022-50366",
    "CVE-2022-50430",
    "CVE-2022-50638",
    "CVE-2023-52572",
    "CVE-2023-53148",
    "CVE-2023-53285",
    "CVE-2023-53357",
    "CVE-2023-53395",
    "CVE-2023-53456",
    "CVE-2023-53596",
    "CVE-2023-53676",
    "CVE-2025-39901",
    "CVE-2025-71093",
    "CVE-2025-71225",
    "CVE-2026-23448",
    "CVE-2026-23455",
    "CVE-2026-31405",
    "CVE-2026-31452",
    "CVE-2026-31607",
    "CVE-2026-31685",
    "CVE-2026-31720",
    "CVE-2026-31787",
    "CVE-2026-43020",
    "CVE-2026-43050",
    "CVE-2026-43051",
    "CVE-2026-43052",
    "CVE-2026-43110",
    "CVE-2026-43190",
    "CVE-2026-43427"
  );
  script_xref(name:"CLSA", value:"2026:1782148320");

  script_name(english:"CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1782148320)");

  script_set_attribute(attribute:"synopsis", value:
"The CentOS Linux host is missing one or more security updates.");
  script_set_attribute(attribute:"description", value:
"The CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the
TuxCare CENTOS7:CLSA-2026:1782148320 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: media: ngene: Fix out-of-bounds bug in
    ngene_command_config_free_buf() Fix an 11-year old bug in ngene_command_config_free_buf() while addressing
    the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning:
    '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject
    'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25:
    warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced
    subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the
    original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue
    FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because
    memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is
    FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also,
    the name of the function ngene_command_config_free_buf() suggests that the actual intention is to
    ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function
    ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct
    FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the
    destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also helps
    with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the
    FORTIFY_SOURCE routines on memcpy(). (CVE-2021-47288)

  - In the Linux kernel, the following vulnerability has been resolved: nvme: fix a possible use-after-free in
    controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl
    readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp.
    The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. ->
    nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host, which in
    turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed,
    submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free In
    order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER
    submission. This addresses the above race in controller resets because the driver during teardown should:
    1. change ctrl state to RESETTING 2. flush async_event_work (as well as other async work elements) So
    after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting
    the AER. (CVE-2022-48790)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix use-after-free for
    aborted TMF sas_task Currently a use-after-free may occur if a TMF sas_task is aborted before we handle
    the IO completion in mpi_ssp_completion(). The abort occurs due to timeout. When the timeout occurs, the
    SAS_TASK_STATE_ABORTED flag is set and the sas_task is freed in pm8001_exec_internal_tmf_task(). However,
    if the I/O completion occurs later, the I/O completion still thinks that the sas_task is available. Fix
    this by clearing the ccb->task if the TMF times out - the I/O completion handler does nothing if this
    pointer is cleared. (CVE-2022-48791)

  - In the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used
    dynamic event is removed After 65536 dynamic events have been added and removed, the type field of the
    event then uses the first type number that is available (not currently used by other events). A type
    number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to
    logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced
    and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be
    created and destroyed), if another dynamic event is created that has the same number that new event's
    logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash
    the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2
    $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will
    remove the old event and create a new one (with the same format) and increase the type number to the next
    available on until the type number reaches over 65535 which is the max number for the 16 bit type. After
    it reaches that number, the logic to allocate a new number simply looks for the next available number.
    When an dynamic event is removed, that number is then available to be reused by the next dynamic event
    created. That is, once the above reaches the max number, the number assigned to the event in that loop
    will remain the same. Now that means deleting one dynamic event and created another will reuse the
    previous events type number. This is where bad things can happen. After the above loop finishes, the
    kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 >
    kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and
    create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' >
    kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo:
    (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240)
    arg1=
    cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240)
    arg1=
    cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240)
    arg1=
    cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240)
    arg1= ---truncated--- (CVE-2022-49006)

  - In the Linux kernel, the following vulnerability has been resolved: dm raid: fix accesses beyond end of
    raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array
    rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks is defined by the number of raid
    metadata and image tupples passed into the target's constructor. In the case of RAID layout changes being
    requested, that number can be different from the current number of members for existing raid sets as
    defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed -
    raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 ->
    raid6) When accessing array members, rs->raid_disks must be used in control loops instead of the
    potentially larger value in rs->md.raid_disks. Otherwise it will cause memory access beyond the end of the
    rs->devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix
    validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up
    raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was
    verified to pass all LVM2 RAID tests (with KASAN enabled). (CVE-2022-49674)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version
number.");
  # https://security.tuxcare.com/csaf/v2/els_os/centos7els/advisories/2026/clsa-2026_1782148320.json
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?63e2bfc8");
  script_set_attribute(attribute:"see_also", value:"https://cve.tuxcare.com/els/releases/CLSA-2026:1782148320");
  script_set_attribute(attribute:"solution", value:
"Update the affected packages based on the guidance in TuxCare advisory CENTOS7:CLSA-2026:1782148320.");
  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:U/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:U/RL:O/RC:C");
  script_set_attribute(attribute:"cvss_score_source", value:"CVE-2026-43020");

  script_set_attribute(attribute:"exploitability_ease", value:"No known exploits are available");
  script_set_attribute(attribute:"exploit_available", value:"false");
  script_set_attribute(attribute:"vendor_severity", value:"Important");

  script_set_attribute(attribute:"vuln_publication_date", value:"2021/07/21");
  script_set_attribute(attribute:"patch_publication_date", value:"2026/06/22");
  script_set_attribute(attribute:"plugin_publication_date", value:"2026/09/30");

  script_set_attribute(attribute:"plugin_type", value:"local");
  script_set_attribute(attribute:"generated_plugin", value:"current");
  script_end_attributes();

  script_category(ACT_GATHER_INFO);
  script_family(english:"CentOS 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_info2.nasl");
  script_require_keys("Host/OS/extended-third-party", "Host/local_checks_enabled", "Host/CentOS/release", "Host/CentOS/rpm-list");

  exit(0);
}
include('rpm2.inc');

var third_party_support = get_kb_item('Host/OS/extended-third-party');
if (empty_or_null(third_party_support) || third_party_support != 'TuxCare') exit(0, 'TuxCare support not enabled.');

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) || 'CentOS Linux' >!< os_product) audit(AUDIT_OS_NOT, 'CentOS Linux');
var os_version = get_kb_item('installed_os/local/SSH/0/version');
if (isnull(os_version)) audit(AUDIT_UNKNOWN_APP_VER, 'CentOS Linux');
if (! preg(pattern:"^7([^0-9]|$)", string:os_version)) audit(AUDIT_OS_NOT, 'CentOS Linux 7', 'CentOS Linux ' + os_version);

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

var cpu = get_kb_item('Host/cpu');
if (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);
if ('x86_64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'CentOS Linux', cpu);


var constraints = [
  {
    'release': '7',
    'pkgs': [
      {'reference':'bpftool-3.10.0-1160.144.1.el7.tuxcare.els7', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-3.10.0-1160.144.1.el7.tuxcare.els7', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-debug-3.10.0-1160.144.1.el7.tuxcare.els7', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-debug-devel-3.10.0-1160.144.1.el7.tuxcare.els7', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-devel-3.10.0-1160.144.1.el7.tuxcare.els7', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-headers-3.10.0-1160.144.1.el7.tuxcare.els7', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-tools-3.10.0-1160.144.1.el7.tuxcare.els7', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-tools-libs-3.10.0-1160.144.1.el7.tuxcare.els7', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-tools-libs-devel-3.10.0-1160.144.1.el7.tuxcare.els7', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'perf-3.10.0-1160.144.1.el7.tuxcare.els7', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'python-perf-3.10.0-1160.144.1.el7.tuxcare.els7', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE}
    ]
  }
];

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-debug / kernel-debug-devel / kernel-devel / etc');
}