Lucene search
+L

CentOS Linux 6 [TuxCare] Security Update: kernel / kernel-abi-whitelists / kernel-debug / kernel-debug-devel / etc Multiple Vulnerabilities (CENTOS6:CLSA-2026:1775745943)

🗓️ 30 Sep 2026 00:00:00Reported by TenableType 
nessus
 nessus
🔗 www.tenable.com👁 5 Views

Buffer overflow in the Linux kernel p54_rx_eeprom_readback() via malicious USB device.

Related
Refs
Code
#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
##

include('compat.inc');

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

  script_cve_id(
    "CVE-2025-38348",
    "CVE-2025-39828",
    "CVE-2026-23074",
    "CVE-2026-23089"
  );
  script_xref(name:"CLSA", value:"2026:1775745943");

  script_name(english:"CentOS Linux 6 [TuxCare] Security Update: kernel / kernel-abi-whitelists / kernel-debug / kernel-debug-devel / etc Multiple Vulnerabilities (CENTOS6:CLSA-2026:1775745943)");

  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 6 host has packages installed that are affected by multiple vulnerabilities as referenced in the
TuxCare CENTOS6:CLSA-2026:1775745943 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: wifi: p54: prevent buffer-overflow in
    p54_rx_eeprom_readback() Robert Morris reported: |If a malicious USB device pretends to be an Intersil p54
    wifi |interface and generates an eeprom_readback message with a large |eeprom->v1.len,
    p54_rx_eeprom_readback() will copy data from the |message beyond the end of priv->eeprom. | |static void
    p54_rx_eeprom_readback(struct p54_common *priv, | struct sk_buff *skb) |{ | struct p54_hdr *hdr = (struct
    p54_hdr *) skb->data; | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data; | | if
    (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else
    { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...] The
    eeprom->v{1,2}.len is set by the driver in p54_download_eeprom(). The device is supposed to provide the
    same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to
    something that causes a crash/panic due to overrun. This patch addresses the issue by adding the size to
    the common device context, so p54_rx_eeprom_readback no longer relies on possibly tampered values... That
    said, it also checks if the firmware altered the value and no longer copies them. The one, small saving
    grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware
    has a proprietary license and as a reason, it is not present on most distributions by default.
    (CVE-2025-38348)

  - In the Linux kernel, the following vulnerability has been resolved: atm: atmtcp: Prevent arbitrary write
    in atmtcp_recv_control(). syzbot reported the splat below. [0] When atmtcp_v_open() or atmtcp_v_close() is
    called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message. The
    message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to
    atmtcp_control.vcc. The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel
    pointer. struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ ... atm_kptr_t vcc; /* both
    directions */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;
    The special message is processed in atmtcp_recv_control() called from atmtcp_c_send(). atmtcp_c_send() is
    vcc->dev->ops->send() and called from 2 paths: 1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2.
    vcc_sendmsg() The problem is sendmsg() does not validate the message length and userspace can abuse
    atmtcp_recv_control() to overwrite any kptr by atmtcp_control. Let's add a new ->pre_send() hook to
    validate messages from sendmsg(). [0]: Oops: general protection fault, probably for non-canonical address
    0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range
    [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted
    6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute
    Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93
    [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8
    03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6
    04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX:
    00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff
    RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10:
    dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f
    R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010
    DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0
    Call Trace: <TASK> vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714
    [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614
    ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg
    net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260
    net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0
    arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28
    00 00 00 75 05 48 83 c4 28 c3 e8 51 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 b0 ff ff ff f7 d8 64 89 01 48 RSP:
    002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX:
    00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005
    RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11:
    0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250
    </TASK> Modules linked in: (CVE-2025-39828)

  - In the Linux kernel, the following vulnerability has been resolved: net/sched: Enforce that teql can only
    be used as root qdisc Design intent of teql is that it is only supposed to be used as root qdisc. We need
    to check for that constraint. Although not important, I will describe the scenario that unearthed this
    issue for the curious. GangMin Kim <[email protected]> managed to concot a scenario as follows: ROOT
    qdisc 1:0 (QFQ)  class 1:1 (weight=15, lmax=16384) netem with delay 6.4s  class 1:2 (weight=1,
    lmax=1514) teql GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ
    from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it
    lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql
    only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek
    succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain
    as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfq_change_class calls
    qfq_deact_rm_from_agg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the
    class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4
    seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF. (CVE-2026-23074)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix use-after-free in
    snd_usb_mixer_free() When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees mixer->id_elems but the
    controls already added to the card still reference the freed memory. Later when snd_card_register() runs,
    the OSS mixer layer calls their callbacks and hits a use-after-free read. Call trace:
    get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40
    sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381
    snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0
    sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025 Fix by calling snd_ctl_remove()
    for all mixer controls before freeing id_elems. We save the next pointer first because snd_ctl_remove()
    frees the current element. (CVE-2026-23089)

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/centos6els/advisories/2026/clsa-2026_1775745943.json
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?50ccf18f");
  script_set_attribute(attribute:"see_also", value:"https://cve.tuxcare.com/els/releases/CLSA-2026:1775745943");
  script_set_attribute(attribute:"solution", value:
"Update the affected packages based on the guidance in TuxCare advisory CENTOS6:CLSA-2026:1775745943.");
  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-23089");

  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:"2025/07/10");
  script_set_attribute(attribute:"patch_publication_date", value:"2026/04/09");
  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:"^6([^0-9]|$)", string:os_version)) audit(AUDIT_OS_NOT, 'CentOS Linux 6', '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 (cpu !~ "^i[3-6]86$" && 'x86_64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'CentOS Linux', cpu);


var constraints = [
  {
    'release': '6',
    'pkgs': [
      {'reference':'kernel-2.6.32-754.35.8.el6.tuxcare.els31', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-abi-whitelists-2.6.32-754.35.8.el6.tuxcare.els31', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-debug-2.6.32-754.35.8.el6.tuxcare.els31', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-debug-devel-2.6.32-754.35.8.el6.tuxcare.els31', 'cpu':'i686', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-debug-devel-2.6.32-754.35.8.el6.tuxcare.els31', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-devel-2.6.32-754.35.8.el6.tuxcare.els31', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-firmware-2.6.32-754.35.8.el6.tuxcare.els31', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'kernel-headers-2.6.32-754.35.8.el6.tuxcare.els31', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'perf-2.6.32-754.35.8.el6.tuxcare.els31', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
      {'reference':'python-perf-2.6.32-754.35.8.el6.tuxcare.els31', '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, 'kernel / kernel-abi-whitelists / kernel-debug / kernel-debug-devel / etc');
}

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation

30 Sep 2026 00:00Current
5.9Medium risk
Vulners AI Score5.9
CVSS 3.17 - 7.8
EPSS0.00188
SSVC
5