From c77a05b32b2f63a5cefb610c25affbe3a5afe807 Mon Sep 17 00:00:00 2001 From: Ben Hutchings Date: Thu, 23 Feb 2017 21:55:28 +0000 Subject: Retire many issues now released (or N/A or ignored) in all branches git-svn-id: svn+ssh://svn.debian.org/svn/kernel-sec@5001 e094ebfe-e918-0410-adfb-c712417f3574 --- retired/CVE-2012-6704 | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 retired/CVE-2012-6704 (limited to 'retired/CVE-2012-6704') diff --git a/retired/CVE-2012-6704 b/retired/CVE-2012-6704 new file mode 100644 index 00000000..38f08b67 --- /dev/null +++ b/retired/CVE-2012-6704 @@ -0,0 +1,22 @@ +Description: net: Negative socket receive buffer size permitted +References: +Notes: + bwh> Prior to commit 82981930125a "net: cleanups in sock_setsockopt()": + bwh> - The comparison with SOCK_MIN_SNDBUF used type int, so it + bwh> rejected negative values + bwh> - The comparison with SOCK_MIN_RCVBUF used type size_t, so it did + bwh> *not* reject negative values + bwh> - The comparisons of val with sysctl_wmem_max used type u32, so + bwh> they rejected negative values *unless* sysctl_wmem_max >= + bwh> 1 << 30 (and why would you set it that high?!) + bwh> So it was possible to set a negative value for sock::sk_rcvbuf + bwh> through SO_RCVBUFFORCE (escalation from CAP_NET_ADMIN to kernel) + bwh> or through SO_RCVBUF (escalation from user to kernel) iff + bwh> sysctl_wmem_max was large enough. +Bugs: +upstream: released (3.5-rc1) [82981930125abfd39d7c8378a9cfdf5e1be2002b] +3.16-upstream-stable: N/A "Fixed before initial 3.16 release" +3.2-upstream-stable: released (3.2.85) [net-cleanups-in-sock_setsockopt.patch] +sid: released (3.8.11-1) +3.16-jessie-security: N/A "Fixed before initial 3.16 release" +3.2-wheezy-security: released (3.2.84-1) [bugfix/all/net-cleanups-in-sock_setsockopt.patch] -- cgit v1.2.3