Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 Jul 2022 18:05:08 +0200
From: Solar Designer <>
Cc: Hugues ANGUELKOV <>
Subject: Re: Linux kernel: Netfilter heap buffer overflow in nft_set_elem_init

Proposed fix by the maintainer:

netdev thread leading to there starts here:

> ----- Forwarded message from Hugues ANGUELKOV <> -----

> One of our collaborators at RandoriSec, Arthur Mongodin found a 
> vulnerability within the netfilter subsystem during his internship.
> Successful exploitation of this bug leads to a Local Privilege 
> Escalation (LPE) to the `root` user, as tested on Ubuntu server 22.04 
> (Linux 5.15.0-39-generic).
> This vulnerability is a heap buffer overflow due to a weak check and has 
> been introduced within the commit 
> [fdb9c405e35bdc6e305b9b4e20ebc141ed14fc81](, 
> it affects the Linux kernel since the version 5.8 and is still present 
> today.

The fix commit above says it Fixes an older commit from 2015
(7d7402642eaf), but the bug was likely only exposed later, by the 2020
commit referenced in RandoriSec's message above.  Quoting from:

   Insufficient validation of element datatype and length in
   nft_setelem_parse_data(). At least commit 7d7402642eaf updates
   maximum element data area up to 64 bytes when only 16 bytes
   where supported at the time. Support for larger element size
   came later in fdb9c405e35b though. Picking this older commit
   as Fixes: tag to be safe than sorry.

> The vulnerable code path can be reached if the kernel is built with the 
> configuration `CONFIG_NETFILTER`, `CONFIG_NF_TABLES` enabled.
> To exploit the vulnerability, an attacker may need to obtain an 
> unprivileged user namespace to gain the capability `CAP_NET_ADMIN` 
> (`CONFIG_USER_NS` and `CONFIG_NET_NS` enabled, and 
> `kernel.unprivileged_userns_clone = 1`).

Another scenario is the attacker having (or gaining by other means)
"root" access inside a pre-existing container with CAP_NET_ADMIN.  This
does not require unprivileged user namespaces as the container may have
been started by host root.

> we can 
> suggest the August, 15th 2022 as a potential date for public disclosure.

FWIW, an embargo this long wouldn't have been accepted by linux-distros.
The latest this issue could be disclosed publicly is July 15th.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.