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

  - In the Linux kernel, the following vulnerability has been resolved: net: sched: act_csum: validate nested     VLAN headers tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries     in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN     bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an     inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the     following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb,     VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully     available, drop the packet through the existing error path. (CVE-2026-31684)

  - In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on     shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs     with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first     make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into     UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned     nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and     decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags     with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is     present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use     the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that     appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for     nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive.
    Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().
    (CVE-2026-43284)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: strictly check     for maximum number of actions The maximum number of flowtable hardware offload actions in IPv6 is: *     ethernet mangling (4 payload actions, 2 for each ethernet address) * SNAT (4 payload actions) * DNAT (4     payload actions) * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. *     Redirect (1 action) Which makes 17, while the maximum is 16. But act_ct supports for tunnels actions too.
    Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload     actions. Update flow_action_entry_next() calls to check for the maximum number of supported actions. While     at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.
    (CVE-2026-43329)

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

Detections

Analytics

CentOS 9 : kernel-5.14.0-708.el9

medium Nessus Plugin ID 316888

Version 1.2

Version 1.1

Version 1.2 May 29, 2026, 5:27 PM Exploit attributes ("Exploit framework core" set to "True") Exploit attributes ("Exploit framework metasploit" set to "True") Exploit attributes ("Exploited by malware" set to "True") Plugin Feed: 202605291727
Version 1.1 May 27, 2026, 7:09 AM New Plugin Feed: 202605270709