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: <1426080308.11398.37.camel@edumazet-glaptop2.roam.corp.google.com>
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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ