netdev - Re: [net-next PATCH] net: ipv4: fix listify ip_rcv

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: <20180712.164142.1404268131433458085.davem@davemloft.net>
Date:   Thu, 12 Jul 2018 16:41:42 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     brouer@...hat.com
Cc:     ecree@...arflare.com, netdev@...r.kernel.org
Subject: Re: [net-next PATCH] net: ipv4: fix listify ip_rcv_finish in case
 of forwarding

From: Jesper Dangaard Brouer <brouer@...hat.com>
Date: Wed, 11 Jul 2018 17:01:20 +0200

> In commit 5fa12739a53d ("net: ipv4: listify ip_rcv_finish") calling
> dst_input(skb) was split-out.  The ip_sublist_rcv_finish() just calls
> dst_input(skb) in a loop.
> 
> The problem is that ip_sublist_rcv_finish() forgot to remove the SKB
> from the list before invoking dst_input().  Further more we need to
> clear skb->next as other parts of the network stack use another kind
> of SKB lists for xmit_more (see dev_hard_start_xmit).
> 
> A crash occurs if e.g. dst_input() invoke ip_forward(), which calls
> dst_output()/ip_output() that eventually calls __dev_queue_xmit() +
> sch_direct_xmit(), and a crash occurs in validate_xmit_skb_list().
> 
> This patch only fixes the crash, but there is a huge potential for
> a performance boost if we can pass an SKB-list through to ip_forward.
> 
> Fixes: 5fa12739a53d ("net: ipv4: listify ip_rcv_finish")
> Signed-off-by: Jesper Dangaard Brouer <brouer@...hat.com>
> ---
> Only driver sfc actually uses this, but I don't have this NIC, so I
> tested this on mlx5, with my own changes to make it use netif_receive_skb_list(),
> but I'm not ready to upstream the mlx5 driver change yet.

Applied, thanks Jesper.

This whole:

	list_del();
	skb->next = NULL;

business is exactly the kind of dragons I was worried about when starting
to use list_head with SKBs.

There is a similar fix wrt. the GRO stuff that I'm about to apply as well.

It definitely is better if we don't have to forcefully hand off NULL
->next next pointers like this in the long term.