netdev - Re: [PATCH net 1/2] ip_tunnel: Fix a memory corruption in ip_tunnel

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:	Mon, 30 Sep 2013 14:40:26 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	pshelar@...ira.com
Cc:	steffen.klassert@...unet.com, netdev@...r.kernel.org
Subject: Re: [PATCH net 1/2] ip_tunnel: Fix a memory corruption in
 ip_tunnel_xmit

From: Pravin Shelar <pshelar@...ira.com>
Date: Fri, 27 Sep 2013 19:34:59 -0700

> All callers of iptunnel_xmit() are required to setup sufficient
> headroom. So skb_push check are not necessary.

This bug shows that such a check is needed, and would have saved
people like Steffen lots of time tracking down the problem.

I think we should re-instate the check.

I also think that __skb_push() is quite dangerous, in general.  And if
it is to be used at all, it should only be used in circumstances where
all of the context necessary to assert that it cannot underflow the
buffer are right there in the same function.

In fact, the whole damn reason for the assertions in skb_push() is the
catch cases where preconditions are not met across functional
boundaries.  Exactly like the case here.

So again, __skb_push() should be changed back to skb_push() here.

Steffen can you respin these patches and make sure to:

1) Add reference to SHA1_ID and commit header line of commit
   introducing this bug, as Eric requested, in this format:

	$SHA1_ID ("Commit header line text.")

2) __skb_push() --> skb_push()

Thank you.
--
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