summaryrefslogtreecommitdiff
path: root/ipc/shm.c
AgeCommit message (Collapse)Author
2006-04-17[PATCH] shmat: stop mprotect from giving write permission to a readonly ↵Hugh Dickins
attachment (CVE-2006-1524) I found that all of 2.4 and 2.6 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. I haven't tried 2.2, but the 2.2.26 source looks like it gets it right; and the patch below reproduces that behaviour - mprotect cannot be used to add write permission to a shared memory segment attached readonly. This patch is simple, and I'm sure it's what we should have done in 2.4.0: if you want to go on to switch write permission on and off with mprotect, just don't attach the segment readonly in the first place. However, we could have accumulated apps which attach readonly (even though they would be permitted to attach read/write), and which subsequently use mprotect to switch write permission on and off: it's not unreasonable. I was going to add a second ipcperms check in do_shmat, to check for writable when readonly, and if not writable find_vma and clear VM_MAYWRITE. But security_ipc_permission might do auditing, and it seems wrong to report an attempt for write permission when there has been none. Or we could flag the vma as SHM, note the shmid or shp in vm_private_data, and then get mprotect to check. But the patch below is a lot simpler: I'd rather stick with it, if we can convince ourselves somehow that it'll be safe. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-02-10[PATCH] shmdt cannot detach not-alined shm segment cleanly.KAMEZAWA Hiroyuki
sys_shmdt() can manage shm segments which are covered by multiple vmas. (This can happen when a user uses mprotect() after shmat().) This works well if shm is aligned to PAGE_SIZE, but if not, the last segment cannot be detached. It is because a comparison in sys_shmdt() (vma->vm_end - addr) < size addr == return address of shmat() size == shmsize, argments to shmget() size should be aligned to PAGE_SIZE before being compared with vma->vm_end, which is aligned. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Manfred Spraul <manfred@colorfullife.com> Acked-by: Hugh Dickins <hugh@veritas.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-11[PATCH] move capable() to capability.hRandy.Dunlap
- Move capable() from sched.h to capability.h; - Use <linux/capability.h> where capable() is used (in include/, block/, ipc/, kernel/, a few drivers/, mm/, security/, & sound/; many more drivers/ to go) Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-08[PATCH] ipc: expand shm_flagsAndrew Morton
Unobfsucate this struct member Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06[PATCH] NOMMU: Make SYSV IPC SHM use ramfs facilities on NOMMUDavid Howells
The attached patch makes the SYSV IPC shared memory facilities use the new ramfs facilities on a no-MMU kernel. The following changes are made: (1) There are now shmem_mmap() and shmem_get_unmapped_area() functions to allow the IPC SHM facilities to commune with the tiny-shmem and shmem code. (2) ramfs files now need resizing using do_truncate() rather than by modifying the inode size directly (see shmem_file_setup()). This causes ramfs to attempt to bind a block of pages of sufficient size to the inode. (3) CONFIG_SYSVIPC is no longer contingent on CONFIG_MMU. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07[PATCH] SHM_NORESERVE flags for shmget()Badari Pulavarty
Add SHM_NORESERVE functionality similar to MAP_NORESERVE for shared memory segments. This is mainly to avoid abuse of OVERCOMMIT_ALWAYS and this flag is ignored for OVERCOMMIT_NEVER. Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] hugetlb: remove repeated codeKrishnakumar R
Clean up some repeated code related to HugeTLB. hugetlb_zero_setup would have already allocated the file->f_op. Signed-off-by: Krishnakumar. R <rkrishnakumar@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07[PATCH] ipc: convert /proc/sysvipc/* to generic seq_file interfaceMike Waychison
Change the /proc/sysvipc/shm|sem|msg files to use the generic seq_file implementation for struct ipc_ids. Signed-off-by: Mike Waychison <mikew@google.com> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-01[PATCH] shm: CONFIG_SHMEM=n build fixAndrew Morton
Fix bug found by Grant Coady <lkml@dodo.com.au>'s autobuild setup. shmem_set_policy() and shmem_get_policy() are macros if !CONFIG_SHMEM, so this doesn't work. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] consolidate sys_shmatStephen Rothwell
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!