Google: sys-kernel/cchost-kernel-6_12, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_6, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_6, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_6, sys-kernel/lakitu-vgpu-kernel-6_6: security update to 19216.655.28

medium Tenable Cloud Security Plugin ID 468785

Description

There are packages installed that are affected by a vulnerability referenced in the following CVE:

- In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: don't queue
packet path object notifications All file:line references below are against v7.2-rc4 (ac5b0e5651b1). The
trace was captured on 7.2.0-rc6-kasan72rc6 (075b74841bd0), where the same lines apply. nft_obj_notify() is
exported and reached from the packet path. Its only in-tree caller is nft_quota_obj_eval()
(net/netfilter/nft_quota.c:68), which notifies with GFP_ATOMIC while evaluating a rule for a transiting
packet, holding no mutex. Since commit 67cc570edaa0 ("netfilter: nf_tables: coalesce multiple
notifications into one skbuff") that notification is no longer sent immediately. __nft_obj_notify() queues
it onto nft_net->notify_list via nft_notify_enqueue() (net/netfilter/nf_tables_api.c:1211), which is a
bare list_add_tail(). notify_list has no lock of its own (include/net/netfilter/nf_tables.h:1951), it is
serialised by commit_mutex: the six other enqueue sites all run inside a netlink transaction, and the
drain in nft_commit_notify() (net/netfilter/nf_tables_api.c:10746) does list_del() + kfree_skb() from
nf_tables_commit() with commit_mutex held. Sending packets through a chain that references a depleted
quota object therefore races an unlocked list_add_tail() against list_del() + kfree_skb() on another CPU.
The WRITE_ONCE(prev->next, new) in __list_add() then stores through an sk_buff that has already been
freed: BUG: KASAN: slab-use-after-free in __nft_obj_notify+0x2c5/0x2d0 Write of size 8 at addr
ff110001047183c0 by task poc/76 CPU: 0 UID: 1000 PID: 76 Comm: poc Tainted: G W 7.2.0-rc6-kasan72rc6 #4
Call Trace: <IRQ> __nft_obj_notify (include/linux/list.h:164 include/linux/list.h:191
net/netfilter/nf_tables_api.c:1211 net/netfilter/nf_tables_api.c:8743) nft_quota_obj_eval
(net/netfilter/nft_quota.c:68) nft_do_chain_inet nf_hook_slow __ip_local_out ip_push_pending_frames
udp_send_skb udp_sendmsg __x64_sys_sendto Allocated by task 77: __alloc_skb (net/core/skbuff.c:704)
__nft_obj_notify (include/net/netlink.h:1055 net/netfilter/nf_tables_api.c:8731) nft_quota_obj_eval
(net/netfilter/nft_quota.c:68) nft_do_chain Freed by task 79: nf_tables_commit
(include/linux/skbuff.h:1332 net/netfilter/nf_tables_api.c:10759 net/netfilter/nf_tables_api.c:11185)
nfnetlink_rcv_batch (net/netfilter/nfnetlink.c:574) netlink_unicast netlink_sendmsg The buggy address
belongs to the cache skbuff_head_cache of size 232 Queueing from the packet path is wrong even leaving the
race aside: notify_list is only drained by nft_commit_notify() from nf_tables_commit() (:11185), so a
notification enqueued outside a transaction is not sent until some later netlink batch commits, if one
ever does. The gfp argument that nft_obj_notify() still takes is a leftover of the pre-67cc570edaa0
behaviour, where this path called nfnetlink_send() directly. Restore that: split the message construction
out into nft_obj_notify_alloc() and let each caller decide what to do with the skb. nft_obj_notify(), the
exported one reached from the packet path, sends it straight away; nf_tables_obj_notify(), which runs
under commit_mutex, keeps queueing it, so transaction notifications are still coalesced. (CVE-2026-80837)

Solution

Update the sys-kernel/cchost-kernel-6_12 library and its related packages to version 19216.655.28 or later.

See Also

https://storage.googleapis.com/cos-oval-vulnerability-feed/cos-125.oval.xml.tar.gz

Plugin Details

Severity: Medium

ID: 468785

Version: Revision 1.5

Type: Local

Published: 10/3/2026

Updated: 10/6/2026

Supported Sensors: Tenable Cloud Security, Tenable Self-Hosted Container Security

Risk Information

VPR

Risk Factor: Low

Score: 3

Percentile: 23.66

Vendor

Vendor Severity: LOW

CVSS v2

Risk Factor: Medium

Base Score: 5.6

Temporal Score: 4.1

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

CVSS Score Source: CVE-2026-80837

CVSS v3

Risk Factor: Medium

Base Score: 5.5

Temporal Score: 4.8

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

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

Vulnerability Information

Exploit Ease: No known exploits are available

Vulnerability Publication Date: 9/4/2026

Reference Information

CVE: CVE-2026-80837