netdev - Re: ppp/l2tp doing oversized allocations ?

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] [day] [month] [year] [list]

Date:	Sat, 19 May 2012 02:34:32 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	davej@...hat.com, netdev@...r.kernel.org,
	kernel-team@...oraproject.org, edumazet@...gle.com
Subject: Re: ppp/l2tp doing oversized allocations ?

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Sat, 19 May 2012 08:25:30 +0200

> On Sat, 2012-05-19 at 07:01 +0200, Eric Dumazet wrote:
>> On Sat, 2012-05-19 at 00:46 -0400, David Miller wrote:
>> 
>> > So it's ESP encapsulated IPSEC over L2tp.
>> > 
>> > Eric, I wonder if session->hdr_len can take on undesirable values and
>> > thus trip up the skb COW'ing calculations you added?
>> 
>> I take a look, thanks
>> 
> 
> hdr_len is u16, I have no idea how we can reach MAX_ORDER page
> allocations... (more than 2 Mbytes...)
> 
> Maybe a memory corruption, or a signed/unsigned mismatch.

Yes, the trace looks really weird to me too.

It's also possible that the big length comes accidently from IPSEC
too.

If this can be readily reproduced, we can construct some debugging
patches for the user to try.
--
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