netdev - Re: [PATCH] net: sysctl_net_core: check SNDBUF and RCVBUF for min length

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:	Wed, 11 Mar 2015 06:25:08 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Alexey Kodanev <alexey.kodanev@...cle.com>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	vasily.isaenko@...cle.com
Subject: Re: [PATCH] net: sysctl_net_core: check SNDBUF and RCVBUF for min
 length

On Wed, 2015-03-11 at 14:29 +0300, Alexey Kodanev wrote:
> sysctl has sysctl.net.core.rmem_*/wmem_* parameters which can be
> set to incorrect values. Given that 'struct sk_buff' allocates from
> rcvbuf, incorrectly set buffer length could result to memory
> allocation failures. For example, set them as follows:
> 
>     # sysctl net.core.rmem_default=64
>       net.core.wmem_default = 64
>     # sysctl net.core.wmem_default=64
>       net.core.wmem_default = 64
>     # ping localhost -s 1024 -i 0 > /dev/null
> 

Yeah, root users seem to act like monkeys these days ;)

Note the real bug is in unix_stream_sendmsg(), as it assumes
 sk_sndbuf > 130 :

	/* Keep two messages in the pipe so it schedules better */
	size = min_t(int, size, (sk->sk_sndbuf >> 1) - 64);

The 64 here seems to assume skb overhead of linux 0.1 on a hypothetical
16bit host ;)

I guess your fix is fine, but might break applications that were
expecting that sysctl net.core.wmem_default=512  would effectively limit
queue occupancy to one skb (without crashing unix_stream_sendmsg())

As commit eea86af6b1e18d6fa did not trigger bug reports, I think we
should get your patch, and eventually adjust SOCK_MIN_SNDBUF if required
later.

Note that we should also limit max value, because of possible arithmetic
overflows for sk->sk_wmem_alloc.

A max of (1U << 31) might be reasonable ?




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