All of 2.4 and 2.6 kernels have been letting mprotect give write permission to a readonly attachment of shared memory, whether or not IPC would give the caller that permission. SUS says "The behaviour of this function [mprotect] is unspecified if the mapping was not established by a call to mmap", but I don't think we can interpret that as allowing it to subvert IPC permissions.
The upstream fix can be found here: http://www.kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git;a=commit;h=0dba0f6b382bf360a1974fd78538273478dfc784
This is _not_ CVE-2006-1524. The commit message of the upstream fix is wrong.
Created attachment 128372 [details] shm/mprotect testcase.
.live.[root@i386-21as root]# ./maywrite shm segment attached at 0x40018000 shmaddr)[512] = .live.[root@i386-21as root]# echo $? 0 .live.[root@i386-21as root]# uname -a Linux i386-21as.test.redhat.com 2.4.9-e.68smp #1 SMP Thu Jan 19 18:38:50 EST 2006 i686 unknown .qa.[root@i386-21as-bos root]# uname -a Linux i386-21as-bos.lab.boston.redhat.com 2.4.9-e.70 #1 Fri May 5 21:12:54 EDT2006 i686 unknown .qa.[root@i386-21as-bos root]# gcc maywrite.c -o maywrite .qa.[root@i386-21as-bos root]# ./maywrite shm segment attached at 0x40018000 shmaddr)[512] = mprotect() failed: Permission denied Fix looks good!
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2006-0579.html