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

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

include('compat.inc');

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

  script_cve_id(
    "CVE-2024-43839",
    "CVE-2024-47659",
    "CVE-2024-47701",
    "CVE-2024-47742",
    "CVE-2024-47745",
    "CVE-2024-49860",
    "CVE-2024-49882",
    "CVE-2024-49889",
    "CVE-2024-49894",
    "CVE-2024-49950",
    "CVE-2024-49960",
    "CVE-2024-49967",
    "CVE-2024-49991",
    "CVE-2024-50007",
    "CVE-2024-50033",
    "CVE-2024-50035",
    "CVE-2024-50055",
    "CVE-2024-50073"
  );
  script_xref(name:"CLSA", value:"2024:1731348593");

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

  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-2024:1731348593 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: bna: adjust 'name' buf size of bna_tcb
    and bna_ccb structures To have enough space to write all possible sprintf() args. Currently 'name' size is
    16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is
    used there. For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum,
    BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16
    And replace sprintf with snprintf. Detected using the static analysis tool - Svace. (CVE-2024-43839)

  - In the Linux kernel, the following vulnerability has been resolved: smack: tcp: ipv4, fix incorrect
    labeling Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects
    to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets
    are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to
    write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack
    in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule
    'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment) * At S, at label 'bar', launch a
    program that listens for incoming tcp/ipv4 connections * From C, at label 'foo', connect to the listener
    at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works. * Send some data
    in both directions. * Collect network traffic of this connection. All packets in both directions are
    labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized,
    and even without ever being known at C. If anybody cares: exactly the same happens with DCCP. This
    behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no
    explanation was provided. I changed returned packes label into the 'bar', to bring it into line with the
    Smack documentation claims. (CVE-2024-47659)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr
    changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is
    changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds
    access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem
    00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity
    change from 2048 to 2047 ================================================================== BUG: KASAN:
    use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f
    by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted
    6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
    1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline]
    dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline]
    print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601
    ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697
    __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline]
    ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633
    filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat
    fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0
    fs/namei.c:4607 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230
    arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00
    00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP:
    002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX:
    0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0
    RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11:
    0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0
    </TASK> Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a
    check of the validity of the xattrs, avoiding this problem. (CVE-2024-47701)

  - In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal
    Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where
    the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel
    where firmware file names contain string components that are passed through from a device or semi-
    privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: -
    lpfc_sli4_request_firmware_update() seems to construct the firmware filename from ModelName, a string
    that was previously parsed out of some descriptor (Vital Product Data) in lpfc_fill_vpd() -
    nfp_net_fw_find() seems to construct a firmware filename from a model name coming from
    nfp_hwinfo_lookup(pf->hwinfo, nffw.partno), which I think parses some descriptor that was read from the
    device. (But this case likely isn't exploitable because the format string looks like netronome/nic_%s,
    and there shouldn't be any *folders* starting with netronome/nic_. The previous case was different
    because there, the %s is *at the start* of the format string.) - module_flash_fw_schedule() is reachable
    from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning
    CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-
    provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network
    namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack
    path in practice.) Fix it by rejecting any firmware names containing .. path components. For what it's
    worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.
    (CVE-2024-47742)

  - In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM
    hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't
    contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and
    remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX,
    bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the
    remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker
    to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same
    thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz =
    sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, test, 0); const char *buf = mmap(NULL, 4 *
    pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality,
    0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz,
    0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd
    = open(/proc/self/maps, O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024);
    if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx
    7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]
    (CVE-2024-47745)

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/2024/clsa-2024_1731348593.json
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?8465441e");
  script_set_attribute(attribute:"see_also", value:"https://cve.tuxcare.com/els/releases/CLSA-2024:1731348593");
  script_set_attribute(attribute:"solution", value:
"Update the affected packages based on the guidance in TuxCare advisory CENTOS7:CLSA-2024:1731348593.");
  script_set_cvss_base_vector("CVSS2#AV:N/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:N/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-2024-47659");

  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:"2023/12/12");
  script_set_attribute(attribute:"patch_publication_date", value:"2024/11/11");
  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.119.1.el7.tuxcare.els12', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-3.10.0-1160.119.1.el7.tuxcare.els12', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-debug-3.10.0-1160.119.1.el7.tuxcare.els12', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-debug-devel-3.10.0-1160.119.1.el7.tuxcare.els12', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-devel-3.10.0-1160.119.1.el7.tuxcare.els12', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-headers-3.10.0-1160.119.1.el7.tuxcare.els12', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-tools-3.10.0-1160.119.1.el7.tuxcare.els12', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-tools-libs-3.10.0-1160.119.1.el7.tuxcare.els12', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-tools-libs-devel-3.10.0-1160.119.1.el7.tuxcare.els12', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'perf-3.10.0-1160.119.1.el7.tuxcare.els12', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'python-perf-3.10.0-1160.119.1.el7.tuxcare.els12', '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_HOLE,
      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');
}