{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.13-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003enotify_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-\u003enext, 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:    \u003cIRQ\u003e    __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.",
  "id": "DEBIAN-CVE-2026-80837",
  "modified": "2026-09-14T16:47:47.289322008Z",
  "published": "2026-09-04T16:18:12.030Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-80837"
    }
  ],
  "upstream": [
    "CVE-2026-80837"
  ]
}