affected versions: 2.2 up to 2.2.25, 2.4 up to 2.4.24, 2.6 up to 2.6.2 http://isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt
GLSA and what's already fixed status is available at http://dev.gentoo.org/~plasmaroo/glsa-test/frame-view.php?id=8db39c0bb16c6143fbb68985a47fdd6d
*** Bug 42031 has been marked as a duplicate of this bug. ***
Before you release that GLSA, there are a couple of other vulnerabilities to clear up. I noticed in RedHat's advisory for this vuln, they also addressed 3 other vulns. One (CAN-2004-0003) was fixed in 2.4.22. The others (CAN-2004-0010 and CAN-2004-0075) are present in the gentoo-sources-2.4.22-r7 kernel that was just released. CAN-2004-0003 is a vuln in ncpfs. CAN-2004-0075 is a vuln in the Vicam USB driver. They still show up as reserved at cve.mitre.org. I will attach patches for both from the latest kernel (RedHat uses these same patches). They both apply cleanly to the gentoo-sources-2.4.22-r7 kernel currently in Portage. The ncpfs fix is not trivial but it works fine in my testing. Sorry I haven't tried any other kernels.
Created attachment 25878 [details, diff] Vicam USB driver patch for CAN-2004-0075 Vicam USB driver patch for CAN-2004-0075
Created attachment 25879 [details, diff] ncpfs patch for CAN-2004-0010 ncpfs patch for CAN-2004-0010
Brian, could you please put these other two patches in -r8 whenever you'll release it? Thanks.
Wheee! More security patches to throw at you. :( After digging through the source, I've found that CAN-2004-0003 is incorrect when it states that the Rage 128 DRM driver vuln was fixed in 2.4.22. It was really fixed in the latest 2.4.25 kernel. In other words, the latest gentoo-sources-2.4.22-r7 is vulnerable. I will attach the patch used by both the mainline kernel and RedHat, made to apply against gentoo-sources-2.4.22-r7. Also, the latest RedHat kernel fixed a copy_from_user (or lack thereof) vuln in the 3DLabs Gamma DRM driver. This patch doesn't appear to be in the mainline kernel. I've worked it up to apply against gentoo-sources-2.4.22-r7 and will attach it also. In both patches, the DRM-4.1 and DRM-4.0 drivers are updated. The patches will need to be modifed for any kernels that don't provide both. Also, yesterday I meant to say CAN-2004-0010 is a vuln in ncpfs, not CAN-2004-0003 (X copy and paste is a little too easy sometimes). And if these need to go under a new bug, let me know. Thanks!
Created attachment 25949 [details, diff] Check limits in R128 DRI drivers. (CAN-2004-0003)
Created attachment 25950 [details, diff] Fix user/kernel copying in DRI GAMMA driver.
Will there be a fix for 2.4.19?
plasmaroo, sysctl -w vm.max_map_count=1000000 This seems to work around Christophe Devine's POC code for this bug. http://marc.theaimsgroup.com/?l=full-disclosure&m=107711498300202&w=2
Thomas, Here is the mremap patch made to apply against gentoo-sources-2.4.19-r10. It is subtly different than the patch for newer kernels and will NOT apply to kernels newer than 2.4.19.
Created attachment 26198 [details, diff] mremap patch for kernel 2.4.19 Will NOT apply to kernels newer than 2.4.19.
OK, gentoo-sources-2.4.19-r11 is now in CVS. For reference, the attached patch does not apply, but the one in files/ which I used for 2.4.20 applied fine.
That's because there is an error in the 2.4.19-r11 ebuild that is causing none of the patches to get applied. On my box, I get: >>> Unpacking linux-2.4.19.tar.bz2 to /var/tmp/portage/gentoo-sources-2.4.19-r11/work >>> Unpacking patches-2.4.19-gentoo-r10.tar.bz2 to /var/tmp/portage/gentoo-sources-2.4.19-r11/work patching file arch/i386/kernel/entry.S patching file drivers/char/drm/i810_dma.c patching file drivers/char/drm-4.0/i810_dma.c RUNNING FROM extra_functions.sh * Applying do_brk_fix.patch... [ ok ] RUNNING FROM extra_functions.sh * Applying gentoo-sources-2.4.20-munmap.patch... [ ok ] /usr/sbin/ebuild.sh: line 53: cd: 2.4.19-gentoo-r11: No such file or directory rm: cannot remove `*xfs*': No such file or directory rm: cannot remove `70*': No such file or directory Current kernel version is 2.4.19 Scanning patch directory: '.' ls: *_*: No such file or directory during the unpack. This is, I think, because the ebuild is looking for the patch directory in work/2.4.19-gentoo-r11 ( cd ${KV} ) but it was extracted to work/2.4.19-r10. The patch I attached yesterday applies to 2.4.19-r10 because the 06_vm-strict-overcommit patch adds a ",1" to the do_munmap() calls. The -r11 isn't applying the 06_vm-strict-overcommit patch hence the standard kernel patch for this vuln applies to it. If the ebuild is fixed, the patch I made will work, I think. But I'm not claiming to be an expert, just trying to help.
Hmmm. This was fixed and a GLSA was released but this bug was never closed, closing the bug.
