Detections
Analytics

CentOS 9 : kernel-5.14.0-741.el9

critical Nessus Plugin ID 339710

Synopsis

The remote CentOS host is missing one or more security updates for kernel.

Description

The remote CentOS Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the kernel-5.14.0-741.el9 build changelog.

 - In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source- address guard, so the wildcard branch can never reuse a freed transport. (CVE-2026-64564)

 - In the Linux kernel, the following vulnerability has been resolved: sctp: purge outqueue on stale COOKIE- ECHO handling sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed. However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk. During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state. Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free(). This results in crashes such as (reported by Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10 Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIE_WAIT restart. Updating only stream->out_curr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after- free in dequeue paths. (CVE-2026-52924)

 - In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: fix missing locks in invalidating cache blocks In passthrough mode, the policy invalidate_mapping operation is called simultaneously from multiple workers, thus it should be protected by a lock. Otherwise, we might end up with data races on the allocated blocks counter, or even use-after-free issues with internal data structures when doing concurrent writes. Note that the existing FIXME in smq_invalidate_mapping() doesn't affect passthrough mode since migration tasks don't exist there, but would need attention if supporting fast device shrinking via suspend/resume without target reloading. Reproduce steps: 1. Create a cache device consisting of 1024 cache entries dmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 131072 linear /dev/sdc 8192 dmsetup create corig --table 0 262144 linear /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache
 --table 0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. Populate the cache, and record the number of cached blocks fio --name=populate
 --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --size=64m --direct=1 nr_cached=$(dmsetup status cache | awk '{split($7, a, /); print a[1]}') 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table 0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0 dmsetup resume cache 4. Write to the passthrough cache. By setting multiple jobs with I/O size equal to the cache block size, cache blocks are invalidated concurrently from different workers. fio --filename=/dev/mapper/cache --name=test --rw=randwrite --bs=64k \ --direct=1
 --numjobs=2 --randrepeat=0 --size=64m 5. Check if demoted matches cached block count. These numbers should match but may differ due to the data race. nr_demoted=$(dmsetup status cache | awk '{print $12}') echo $nr_cached, $nr_demoted (CVE-2026-53062)

 - In the Linux kernel, the following vulnerability has been resolved: sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing When a listening SCTP server processes a COOKIE_ECHO chunk, the cached peer INIT chunk embedded after the cookie is parsed and its parameters are later walked by sctp_process_init() using sctp_walk_params(). However, the chunk header length of this cached INIT chunk was not validated against the remaining buffer in the COOKIE_ECHO payload. If the length field is inflated, the parameter walk can run beyond the actual received data, leading to out-of-bounds reads and potential memory corruption during later parameter handling (e.g. STATE_COOKIE processing and kmemdup() copies). Add a bounds check in sctp_unpack_cookie() to ensure the cached INIT chunk length does not exceed the available data in the COOKIE_ECHO buffer before it is used. (CVE-2026-53246)

 - 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-53266)

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

Solution

Update the CentOS 9 Stream kernel package.

See Also

https://kojihub.stream.centos.org/koji/buildinfo?buildID=125676

Plugin Details

Severity: Critical

ID: 339710

File Name: centos9_kernel-5_14_0-741_125676.nasl

Version: 1.1

Type: Local

Agent: unix

Published: 8/26/2026

Updated: 8/26/2026

Supported Sensors: Agentless Assessment, Continuous Assessment, Frictionless Assessment Agent, Frictionless Assessment AWS, Frictionless Assessment Azure, Nessus Agent, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus

Risk Information

VPR

Risk Factor: High

Score: 7.9

Percentile: 99.36

CVSS v2

Risk Factor: Critical

Base Score: 10

Temporal Score: 7.8

Vector: CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C

CVSS Score Source: CVE-2026-64564

CVSS v3

Risk Factor: Critical

Base Score: 9.8

Temporal Score: 8.8

Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Temporal Vector: CVSS:3.0/E:P/RL:O/RC:C

Vulnerability Information

CPE: cpe:/a:centos:centos:9, p-cpe:/a:centos:centos:kernel-64k-core, p-cpe:/a:centos:centos:kernel-64k-debug-core, p-cpe:/a:centos:centos:kernel-64k-debug-devel-matched, p-cpe:/a:centos:centos:kernel-64k-debug-devel, p-cpe:/a:centos:centos:kernel-64k-debug-modules-core, p-cpe:/a:centos:centos:kernel-64k-debug-modules-extra, p-cpe:/a:centos:centos:kernel-64k-debug-modules-internal, p-cpe:/a:centos:centos:kernel-64k-debug-modules-partner, p-cpe:/a:centos:centos:kernel-64k-debug-modules, p-cpe:/a:centos:centos:kernel-64k-debug, p-cpe:/a:centos:centos:kernel-64k-devel-matched, p-cpe:/a:centos:centos:kernel-64k-devel, p-cpe:/a:centos:centos:kernel-64k-modules-core, p-cpe:/a:centos:centos:kernel-64k-modules-extra, p-cpe:/a:centos:centos:kernel-64k-modules-internal, p-cpe:/a:centos:centos:kernel-64k-modules-partner, p-cpe:/a:centos:centos:kernel-64k-modules, p-cpe:/a:centos:centos:kernel-64k, p-cpe:/a:centos:centos:kernel-abi-stablelists, p-cpe:/a:centos:centos:kernel-core, p-cpe:/a:centos:centos:kernel-cross-headers, p-cpe:/a:centos:centos:kernel-debug-core, p-cpe:/a:centos:centos:kernel-debug-devel-matched, p-cpe:/a:centos:centos:kernel-debug-devel, p-cpe:/a:centos:centos:kernel-debug-modules-core, p-cpe:/a:centos:centos:kernel-debug-modules-extra, p-cpe:/a:centos:centos:kernel-debug-modules-internal, p-cpe:/a:centos:centos:kernel-debug-modules-partner, p-cpe:/a:centos:centos:kernel-debug-modules, p-cpe:/a:centos:centos:kernel-debug-uki-virt-addons, p-cpe:/a:centos:centos:kernel-debug-uki-virt, p-cpe:/a:centos:centos:kernel-debug, p-cpe:/a:centos:centos:kernel-devel-matched, p-cpe:/a:centos:centos:kernel-devel, p-cpe:/a:centos:centos:kernel-headers, p-cpe:/a:centos:centos:kernel-kmap-internal, p-cpe:/a:centos:centos:kernel-modules-core, p-cpe:/a:centos:centos:kernel-modules-extra, p-cpe:/a:centos:centos:kernel-modules-internal, p-cpe:/a:centos:centos:kernel-modules-partner, p-cpe:/a:centos:centos:kernel-modules, p-cpe:/a:centos:centos:kernel-rt-64k-core, p-cpe:/a:centos:centos:kernel-rt-64k-debug-core, p-cpe:/a:centos:centos:kernel-rt-64k-debug-devel-matched, p-cpe:/a:centos:centos:kernel-rt-64k-debug-devel, p-cpe:/a:centos:centos:kernel-rt-64k-debug-modules-core, p-cpe:/a:centos:centos:kernel-rt-64k-debug-modules-extra, p-cpe:/a:centos:centos:kernel-rt-64k-debug-modules-internal, p-cpe:/a:centos:centos:kernel-rt-64k-debug-modules-partner, p-cpe:/a:centos:centos:kernel-rt-64k-debug-modules, p-cpe:/a:centos:centos:kernel-rt-64k-debug, p-cpe:/a:centos:centos:kernel-rt-64k-devel-matched, p-cpe:/a:centos:centos:kernel-rt-64k-devel, p-cpe:/a:centos:centos:kernel-rt-64k-modules-core, p-cpe:/a:centos:centos:kernel-rt-64k-modules-extra, p-cpe:/a:centos:centos:kernel-rt-64k-modules-internal, p-cpe:/a:centos:centos:kernel-rt-64k-modules-partner, p-cpe:/a:centos:centos:kernel-rt-64k-modules, p-cpe:/a:centos:centos:kernel-rt-64k, p-cpe:/a:centos:centos:kernel-rt-core, p-cpe:/a:centos:centos:kernel-rt-debug-core, p-cpe:/a:centos:centos:kernel-rt-debug-devel-matched, p-cpe:/a:centos:centos:kernel-rt-debug-devel, p-cpe:/a:centos:centos:kernel-rt-debug-modules-core, p-cpe:/a:centos:centos:kernel-rt-debug-modules-extra, p-cpe:/a:centos:centos:kernel-rt-debug-modules-internal, p-cpe:/a:centos:centos:kernel-rt-debug-modules-partner, p-cpe:/a:centos:centos:kernel-rt-debug-modules, p-cpe:/a:centos:centos:kernel-rt-debug, p-cpe:/a:centos:centos:kernel-rt-devel-matched, p-cpe:/a:centos:centos:kernel-rt-devel, p-cpe:/a:centos:centos:kernel-rt-modules-core, p-cpe:/a:centos:centos:kernel-rt-modules-extra, p-cpe:/a:centos:centos:kernel-rt-modules-internal, p-cpe:/a:centos:centos:kernel-rt-modules-partner, p-cpe:/a:centos:centos:kernel-rt-modules, p-cpe:/a:centos:centos:kernel-rt, p-cpe:/a:centos:centos:kernel-selftests-internal, p-cpe:/a:centos:centos:kernel-tools-libs-devel, p-cpe:/a:centos:centos:kernel-tools-libs, p-cpe:/a:centos:centos:kernel-tools, p-cpe:/a:centos:centos:kernel-uki-virt-addons, p-cpe:/a:centos:centos:kernel-uki-virt, p-cpe:/a:centos:centos:kernel-zfcpdump-core, p-cpe:/a:centos:centos:kernel-zfcpdump-devel-matched, p-cpe:/a:centos:centos:kernel-zfcpdump-devel, p-cpe:/a:centos:centos:kernel-zfcpdump-modules-core, p-cpe:/a:centos:centos:kernel-zfcpdump-modules-extra, p-cpe:/a:centos:centos:kernel-zfcpdump-modules-internal, p-cpe:/a:centos:centos:kernel-zfcpdump-modules-partner, p-cpe:/a:centos:centos:kernel-zfcpdump-modules, p-cpe:/a:centos:centos:kernel-zfcpdump, p-cpe:/a:centos:centos:kernel, p-cpe:/a:centos:centos:libperf-devel, p-cpe:/a:centos:centos:libperf, p-cpe:/a:centos:centos:perf, p-cpe:/a:centos:centos:python3-perf, p-cpe:/a:centos:centos:rtla, p-cpe:/a:centos:centos:rv

Required KB Items: Host/local_checks_enabled, Host/CentOS/release, Host/CentOS/rpm-list, Host/cpu

Exploit Available: true

Exploit Ease: Exploits are available

Patch Publication Date: 8/21/2026

Vulnerability Publication Date: 6/3/2026

Reference Information

CVE: CVE-2026-52924, CVE-2026-53062, CVE-2026-53246, CVE-2026-53266, CVE-2026-64276, CVE-2026-64277, CVE-2026-64564