lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YsCWK4rn3mBQSjX+@salvia>
Date:   Sat, 2 Jul 2022 21:02:03 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Hugues ANGUELKOV <hanguelkov@...dorisec.fr>,
        netdev@...r.kernel.org, security@...nel.org, kadlec@...filter.org,
        fw@...len.de, davy <davy@...dorisec.fr>, amongodin@...dorisec.fr,
        torvalds@...uxfoundation.org
Subject: Re: [PATCH v1] netfilter: nf_tables: fix nft_set_elem_init heap
 buffer overflow

On Sat, Jul 02, 2022 at 11:59:48AM -0700, Jakub Kicinski wrote:
> On Sat, 2 Jul 2022 19:59:11 +0200 Hugues ANGUELKOV wrote:
> > From d91007a18140e02a1f12c9627058a019fe55b8e6 Mon Sep 17 00:00:00 2001
> > From: Arthur Mongodin <amongodin@...dorisec.fr>
> > Date: Sat, 2 Jul 2022 17:11:48 +0200
> > Subject: [PATCH v1] netfilter: nf_tables: fix nft_set_elem_init heap buffer
> >  overflow
> 
> You have the headers twice, you may want to trim them or use git
> send-email if v2 is needed.
> 
> > The length used for the memcpy in nft_set_elem_init may exceed the bound
> > of the allocated object due to a weak check in nft_setelem_parse_data.
> > As a user can add an element with a data type NFT_DATA_VERDICT to a set
> > with a data type different of NFT_DATA_VERDICT, then the comparison on the
> > data type of the element allows to avoid the comparaison on the data length
> > This fix forces the length comparison in nft_setelem_parse_data by removing
> > the check for NFT_DATA_VERDICT type.
> 
> > Fixes: fdb9c405e35b ("netfilter: nf_tables: allow up to 64 bytes in the set element data area")
> > Signed-off-by: Arthur Mongodin <amongodin@...dorisec.fr>
> > ---
> >  net/netfilter/nf_tables_api.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
> > index 51144fc66889..07845f211f3e 100644
> > --- a/net/netfilter/nf_tables_api.c
> > +++ b/net/netfilter/nf_tables_api.c
> > @@ -5219,7 +5219,7 @@ static int nft_setelem_parse_data(struct nft_ctx *ctx, struct nft_set *set,
> >  	if (err < 0)
> >  		return err;
> >  
> > -	if (desc->type != NFT_DATA_VERDICT && desc->len != set->dlen) {
> > +	if (desc->len != set->dlen) {
> 
> Looking at the commit under fixes it seems like it changes the check
> from desc->type != ... to set->type != ...
> 
> Seems like either the bug is even older or the fix should be to go back
> to checking set->type. Prolly the former?

Hold on with this, please.

There is a patch coming in a pull request from nf.git

Thanks for reviewing.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ