netdev - Re: [patch v2] net: heap overflow in __audit

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: <CA+55aFwP5NWG9doOqZRy7fBdUpwW-bDwEJxjMV0Yr3q3Y=30Fg@mail.gmail.com>
Date:	Wed, 27 Nov 2013 12:24:41 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Eric Wong <normalperson@...t.net>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	"David S. Miller" <davem@...emloft.net>,
	Network Development <netdev@...r.kernel.org>,
	"security@...nel.org" <security@...nel.org>,
	Jüri Aedla <juri.aedla@...il.com>,
	"# .39.x" <stable@...nel.org>
Subject: Re: [patch v2] net: heap overflow in __audit_sockaddr()

On Wed, Nov 27, 2013 at 3:51 AM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
>
> We have to clamp msg_namelen to max sizeof(struct sockaddr_storage).
> The sendmsg handler will check msg_namelen again and error out correctly if
> the size of msg_name is too short.

Yeah, clamping sounds like the right thing to do at least for
receiving. For sending, you should say "we can't send packets that big
due to memory constraints" (of, for the case of a sockaddr, "to an
address this big"), but for receiving the size of the user space
buffer is kind of irrelevant - if the user gives a bigger buffer than
necessary, who cares? We just need to make sure that the kernel
doesn't then allocate silly-big temporary buffers internally.

There seems to be a patch floating around to clamp things already.

                Linus
--
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