netdev - Re: [PATCH] net: guard against coalescing packets from buggy network drivers

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]

Date:	Fri, 25 Apr 2014 09:49:35 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Svenning Sørensen <sss@...omea.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] net: guard against coalescing packets from buggy
 network drivers

On Fri, 2014-04-25 at 18:01 +0200, Svenning Sørensen wrote:

> You are right, of course, there are more effective ways to catch buggy 
> drivers.
> But they will probably also be much more expensive.
> This one is very cheap, being in a relatively cold path, especially 
> compared to the memcpy in the same path.

It seems you missed the recent tipc thread then.

They are many ways this code path can be abused, your patch only takes
care of one case.

In tipc case, they added skb to shinfo->frag_list without changing
skb->data_len.

So skb_tailroom(to) was not returning 0 as it should.

The invariant should be more strict.

BUG_ON(to->data + to->len != skb_tail_pointer(to));

I still think a BUG() to catch this is better.

There is no guarantee the developer/user will catch a WARN(),
the bug could sit there a long time.

I have no pity for serious bugs like that.

Since you spot buggy drivers, please provide their fixes or at least
name them so that we can take care of them.

Thanks

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html