All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Björn Töpel" <bjorn.topel@gmail.com>
To: Magnus Karlsson <magnus.karlsson@gmail.com>
Cc: "Karlsson, Magnus" <magnus.karlsson@intel.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Netdev <netdev@vger.kernel.org>,
	"Fijalkowski, Maciej" <maciej.fijalkowski@intel.com>,
	Jonathan Lemon <jonathan.lemon@gmail.com>,
	bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf] xsk: fix crash on double free in buffer pool
Date: Thu, 11 Nov 2021 17:53:37 +0100	[thread overview]
Message-ID: <CAJ+HfNju+_PC7nYKqJk6TqK6vSxRXAOd7Mb7a2wkhaqpbfkOAA@mail.gmail.com> (raw)
In-Reply-To: <20211111075707.21922-1-magnus.karlsson@gmail.com>

On Thu, 11 Nov 2021 at 08:57, Magnus Karlsson <magnus.karlsson@gmail.com> wrote:
>
> From: Magnus Karlsson <magnus.karlsson@intel.com>
>
> Fix a crash in the buffer pool allocator when a buffer is double
> freed. It is possible to trigger this behavior not only from a faulty
> driver, but also from user space like this: Create a zero-copy AF_XDP
> socket. Load an XDP program that will issue XDP_DROP for all
> packets. Put the same umem buffer into the fill ring multiple times,
> then bind the socket and send some traffic. This will crash the kernel
> as the XDP_DROP action triggers one call to xsk_buff_free()/xp_free()
> for every packet dropped. Each call will add the corresponding buffer
> entry to the free_list and increase the free_list_cnt. Some entries
> will have been added multiple times due to the same buffer being
> freed. The buffer allocation code will then traverse this broken list
> and since the same buffer is in the list multiple times, it will try
> to delete the same buffer twice from the list leading to a crash.
>
> The fix for this is just to test that the buffer has not been added
> before in xp_free(). If it has been, just return from the function and
> do not put it in the free_list a second time.
>
> Note that this bug was not present in the code before the commit
> referenced in the Fixes tag. That code used one list entry per
> allocated buffer, so multiple frees did not have any side effects. But
> the commit below optimized the usage of the pool and only uses a
> single entry per buffer in the umem, meaning that multiple
> allocations/frees of the same buffer will also only use one entry,
> thus leading to the problem.
>
> Fixes: 47e4075df300 ("xsk: Batched buffer allocation for the pool")
> Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>

Acked-by: Björn Töpel <bjorn@kernel.org>

  reply	other threads:[~2021-11-11 16:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11  7:57 [PATCH bpf] xsk: fix crash on double free in buffer pool Magnus Karlsson
2021-11-11 16:53 ` Björn Töpel [this message]
2021-11-12 15:00 ` patchwork-bot+netdevbpf

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=CAJ+HfNju+_PC7nYKqJk6TqK6vSxRXAOd7Mb7a2wkhaqpbfkOAA@mail.gmail.com \
    --to=bjorn.topel@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jonathan.lemon@gmail.com \
    --cc=maciej.fijalkowski@intel.com \
    --cc=magnus.karlsson@gmail.com \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@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.