All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: Netdev <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	stable@vger.kernel.org, security@kernel.org
Subject: Re: [PATCH] macsec: avoid heap overflow in skb_to_sgvec
Date: Tue, 25 Apr 2017 17:08:28 +0200	[thread overview]
Message-ID: <CAHmME9ovUDJRDA+Td4Y0bfQZEG5pZQo1JC0nYDVqWMOdxAe5kQ@mail.gmail.com> (raw)
In-Reply-To: <20170425145340.GA25241@bistromath.localdomain>

Hi Sabrina,

On Tue, Apr 25, 2017 at 4:53 PM, Sabrina Dubroca <sd@queasysnail.net> wrote:
> Ugh, good catch :/
>
> AFAICT this patch doesn't really help, because NETIF_F_FRAGLIST
> doesn't get tested in paths that can lead to triggering this.

You're right. This fixes the xmit() path, but not the receive path,
which appears to take skbs directly from the upper device.

> I'll post a patch to allocate a properly-sized sg array.

I just posted this series, which should fix things in a robust way:

https://patchwork.ozlabs.org/patch/754861/

If you want to handle fraglists, it might be a decent idea to allocate
things of the proper size, I guess. It's a good opportunity to call
skb_cow_data, which you need to do anyway when modifying skbs, I
think.

Jason

  reply	other threads:[~2017-04-25 15:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21 21:14 [PATCH] macsec: avoid heap overflow in skb_to_sgvec Jason A. Donenfeld
2017-04-24 11:02 ` David Laight
2017-04-24 12:15   ` Jason A. Donenfeld
2017-04-24 17:47 ` David Miller
2017-04-25 14:53 ` Sabrina Dubroca
2017-04-25 15:08   ` Jason A. Donenfeld [this message]
2017-04-25 15:12     ` Sabrina Dubroca
2017-04-25 15:13       ` Jason A. Donenfeld
2017-04-25 15:23         ` [PATCH] macsec: dynamically allocate space for sglist Jason A. Donenfeld
2017-04-25 16:36           ` Sabrina Dubroca
2017-04-25 17:08             ` [PATCH v2] " Jason A. Donenfeld
2017-04-25 20:35               ` Sabrina Dubroca
2017-04-26 18:42               ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHmME9ovUDJRDA+Td4Y0bfQZEG5pZQo1JC0nYDVqWMOdxAe5kQ@mail.gmail.com \
    --to=jason@zx2c4.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sd@queasysnail.net \
    --cc=security@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.