Bugzilla – Bug 54207
VUL-0: CVE-2004-0424: Linux kernel setsockopt MCAST_MSFILTER integer overflow
Last modified: 2021-10-12 13:30:09 UTC
fresh from vendor-sec: Synopsis: Linux kernel setsockopt MCAST_MSFILTER integer overflow Product: Linux kernel Version: 2.4.22 - 2.4.25, 2.6.1 - 2.6.3 Vendor: http://www.kernel.org/ URL: http://isec.pl/vulnerabilities/isec-0015-msfilter.txt Author: Paul Starzetz <ihaquer@isec.pl> Wojciech Purczynski <cliph@isec.pl> Date: April 20, 2004 1. Issue A critical security vulnerability has been found in the Linux kernel in the ip_setsockopt() function code. 2. Details The ip_setsockopt() function code is a subroutine of the setsockopt(2) system call. This function allows manipulation of various options of the IP socket. The MCAST_MSFILTER option can be used to provide the kernel with a list of multicast addresses to be received on the socket. This code has been introduced with the 2.4.22/2.6.1 kernel releases. There is an exploitable integer overflow inside the code handling the MCAST_MSFILTER socket option in the IP_MSFILTER_SIZE macro calculation. The vulnerable code resides in net/ipv4/ip_sockglue.c file: case MCAST_MSFILTER: { /* ... */ msize = IP_MSFILTER_SIZE(gsf->gf_numsrc); msf = (struct ip_msfilter *)kmalloc(msize,GFP_KERNEL); /* ... */ for (i=0; i<gsf->gf_numsrc; ++i) { psin = (struct sockaddr_in *)&gsf->gf_slist[i]; if (psin->sin_family != AF_INET) goto mc_msf_out; msf->imsf_slist[i] = psin->sin_addr.s_addr; } whereas the IP_MSFILTER_SIZE macro is defined as follows: #define IP_MSFILTER_SIZE(numsrc) \ (sizeof(struct ip_msfilter) - sizeof(__u32) \ + (numsrc) * sizeof(__u32)) Integer overflow during kernel memory space calculation may cause the kernel buffer to be overflown with arbitrary values within the for loop code. 3. Impact Proper exploitation of this vulnerability leads to local privilege escalation giving an attacker full super-user privileges. Unsuccesfull exploitation of the vulnerability may lead to a denial-of-service attack causing machine crash or instant reboot. 4. Solution This bug has been fixed in the 2.4.26 and 2.6.4 kernel releases. All users of vulnerable kernels are advised to upgrade to the latest kernel version. For further information please contact your vendor. 5. Credits: Paul Starzetz <ihaquer@isec.pl> discovered the vulnerability over half a year ago. Wojciech Purczynski performed further research and developed exploit code. 6. Copyright Copyright (c) 2004 iSEC Security Research All Rights Reserved.
<!-- SBZ_reproduce --> na
Created attachment 18473 [details] minimal patch from Dave Jones. minimal patch from Dave Jones as posted on vendor-sec.
The issue is public.
9.1 is not affected according to changelog, so setting version to 9.0
The only affected kernel is the SL81 = SLES8SP3 = SL90 kernel. SL91 is not affected nor is SL82 or SL80. SLES9 is unaffected as well, and so is SLES7. Nor are previous SPs from SLES8 affected. I committed a fix to kernel CVS. I'll submit packages to SL9.0 and 8.1. The 8.1 one should end up in SLES8SP3 as well.
Done. Now it's up to autobuild team, security team, QA, and our maintenance ppl to get the kernel out of the door, _if_ this bug is deemed important enough to release a security update.
From: Mark J Cox <mjc@redhat.com> on vendor-sec > Here's the bare minimum fix I'm going to be rolling into our Ernie noticed an inconsistancy in that patch set: > +++ linux-2.4.22/net/ipv4/ip_sockglue.c 2004-04-20 14:10:50.000000000 +0100 > if (GROUP_FILTER_SIZE(gsf->gf_numsrc) < optlen) { > +++ linux-2.4.22/net/ipv6/ipv6_sockglue.c 2004-04-20 14:18:05.000000000 +0100 > + if (GROUP_FILTER_SIZE(gsf->gf_numsrc) > optlen) { So if you're preparing updates based solely on that patch you should definately fix that. Mark So make suire the last > is a < ...
*** Bug 54220 has been marked as a duplicate of this bug. ***
Fsck, I've overlooked the < vs > inconsistency as well. OK, fixed in CVS now. I did not commit a kernel again; Hubert has more security fixes in the queue, but we don't know whether those can be published already.
If this is the signal DoS, fb_copy and cpu_freq issue, they are already public except cpu_freq but there is no disclosure date and we can fire at will.
For the signal DoS, there's no fix out there, is there? And I don't expect a short-term solution ... But there is: fix possible DoS in do_fork(); not yet disclosed from Apr 16.
For the cpu_freq bug I have not yet seen a fix. Will try to come up with one myself. The fb_copy_mem seems incomplete. Andrea posted another one to our kernel list. And yet another one is completely open. Oh well...
Well, we got a L3 request regarding this security issue by IBM last night. Can somebody give an ETA? I don't want to open another bug since I think all people involved are loaded enough with this one.
ETA would be early next week. I have just communicated the details to Mark VanderWiele <markv@us.ibm.com> and Bill Hartner <bhartner@us.ibm.com>.
CAN-2004-0424
Kernels have been submitted and are waiting for check in.
over two days, and still nothing.. how long can it take to check in a package?
they have been checked in in the meantime and are making their way through QA.
kernels are approved and announced.
CVE-2004-0424: CVSS v2 Base Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)