* Re: [PATCH] FIx 'noexec' behavior
@ 2003-12-07 13:39 Alex Riesen
2003-12-07 13:42 ` William Lee Irwin III
2003-12-07 16:19 ` Alex Riesen
0 siblings, 2 replies; 12+ messages in thread
From: Alex Riesen @ 2003-12-07 13:39 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: linux-kernel, Ulrich Drepper
On 2003-12-07 12:17:37, wli wrote:
> You took a fault in do_mmap_pgoff().
...
> + if (file->f_vfsmnt && (prot & PROT_EXEC)) {
> + if (file->f_vfsmnt->mnt_flags & MNT_NOEXEC)
> + return -EPERM;
> + }
I had to put a check for 'file' (as Ulrich suggested).
Otherwise it deadlocks again.
Is it possible for ->f_vfsmnt to be NULL at all? Should it be tested?
diff -Nru a/mm/mmap.c b/mm/mmap.c
--- a/mm/mmap.c Sun Dec 7 14:37:33 2003
+++ b/mm/mmap.c Sun Dec 7 14:37:33 2003
@@ -478,7 +478,7 @@
if (file && (!file->f_op || !file->f_op->mmap))
return -ENODEV;
- if ((prot & PROT_EXEC) && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
+ if ((prot & PROT_EXEC) && file && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
return -EPERM;
if (!len)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] FIx 'noexec' behavior
2003-12-07 13:39 [PATCH] FIx 'noexec' behavior Alex Riesen
@ 2003-12-07 13:42 ` William Lee Irwin III
2003-12-07 16:19 ` Alex Riesen
1 sibling, 0 replies; 12+ messages in thread
From: William Lee Irwin III @ 2003-12-07 13:42 UTC (permalink / raw)
To: Alex Riesen, linux-kernel, Ulrich Drepper
On Sun, Dec 07, 2003 at 02:39:06PM +0100, Alex Riesen wrote:
> I had to put a check for 'file' (as Ulrich suggested).
> Otherwise it deadlocks again.
> Is it possible for ->f_vfsmnt to be NULL at all? Should it be tested?
> diff -Nru a/mm/mmap.c b/mm/mmap.c
> --- a/mm/mmap.c Sun Dec 7 14:37:33 2003
> +++ b/mm/mmap.c Sun Dec 7 14:37:33 2003
> @@ -478,7 +478,7 @@
> if (file && (!file->f_op || !file->f_op->mmap))
> return -ENODEV;
>
> - if ((prot & PROT_EXEC) && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
> + if ((prot & PROT_EXEC) && file && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
> return -EPERM;
>
> if (!len)
This does not resemble the code I was looking at from current bk.
-- wli
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] FIx 'noexec' behavior
2003-12-07 13:39 [PATCH] FIx 'noexec' behavior Alex Riesen
2003-12-07 13:42 ` William Lee Irwin III
@ 2003-12-07 16:19 ` Alex Riesen
1 sibling, 0 replies; 12+ messages in thread
From: Alex Riesen @ 2003-12-07 16:19 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: linux-kernel
On 2003-12-07 13:42:00, wli wrote:
> > I had to put a check for 'file' (as Ulrich suggested).
> > Otherwise it deadlocks again.
> > Is it possible for ->f_vfsmnt to be NULL at all? Should it be tested?
> > diff -Nru a/mm/mmap.c b/mm/mmap.c
> > --- a/mm/mmap.c Sun Dec 7 14:37:33 2003
> > +++ b/mm/mmap.c Sun Dec 7 14:37:33 2003
> > @@ -478,7 +478,7 @@
> > if (file && (!file->f_op || !file->f_op->mmap))
> > return -ENODEV;
> >
> > - if ((prot & PROT_EXEC) && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
> > + if ((prot & PROT_EXEC) && file && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
> > return -EPERM;
> >
> > if (!len)
>
> This does not resemble the code I was looking at from current bk.
>
probably you were looking at the already fixed code:
ChangeSet@1.1512, 2003-12-06 14:34:40-08:00, torvalds@home.osdl.org +1 -0
Fix the PROT_EXEC breakage on anonymous mmap.
Clean up the tests while at it.
if (file) {
if (!file->f_op || !file->f_op->mmap)
return -ENODEV;
if ((prot & PROT_EXEC) && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
return -EPERM;
}
The code I was looking at was the one from Ulrich:
ChangeSet 1.1507 2003/12/04 22:26:06 drepper@redhat.com
[PATCH] Fix 'noexec' behaviour
We should not allow mmap() with PROT_EXEC on mounts marked "noexec",
since otherwise there is no way for user-supplied executable loaders
(like ld.so and emulator environments) to properly honour the
"noexec"ness of the target.
if ((prot & PROT_EXEC) && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
return -EPERM;
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] FIx 'noexec' behavior
2003-12-07 12:06 Alex Riesen
@ 2003-12-07 12:17 ` William Lee Irwin III
0 siblings, 0 replies; 12+ messages in thread
From: William Lee Irwin III @ 2003-12-07 12:17 UTC (permalink / raw)
To: Alex Riesen, Ulrich Drepper, linux-kernel, Andrew Morton, Jon Smirl
On Sun, Dec 07, 2003 at 01:06:34PM +0100, Alex Riesen wrote:
> mozilla-bin D 00000001 0 1225 1 1245 1393 (NOTLB)
> eba79df4 00000082 c18dac80 00000001 00000003 5a5a5a5a 5a5a5a5a 5a5a5a5a
> 5a5a5a5a 5a5a5a5a 5a5a5a5a 5a5a5a5a 5a5a5a5a 5a5a5a5a c18dac80 00008714
> 65e68354 00000130 f6efd940 f689d4dc f6efd940 fffeffff eba79e14 c01bcd27
Slab poison on the stack is likely from uninitialized stack variables.
On Sun, Dec 07, 2003 at 01:06:34PM +0100, Alex Riesen wrote:
> Call Trace:
> [rwsem_down_failed_common+157/342] rwsem_down_failed_common+0x9d/0x156
> [<c01bcd27>] rwsem_down_failed_common+0x9d/0x156
> [do_page_fault+0/1416] do_page_fault+0x0/0x588
> [<c011d6b1>] do_page_fault+0x0/0x588
> [rwsem_down_read_failed+41/50] rwsem_down_read_failed+0x29/0x32
> [<c01bca95>] rwsem_down_read_failed+0x29/0x32
> [.text.lock.fault+27/131] .text.lock.fault+0x1b/0x83
> [<c011dc54>] .text.lock.fault+0x1b/0x83
> [buffered_rmqueue+237/404] buffered_rmqueue+0xed/0x194
> [<c01433c8>] buffered_rmqueue+0xed/0x194
> [pte_chain_alloc+143/148] pte_chain_alloc+0x8f/0x94
> [<c015480b>] pte_chain_alloc+0x8f/0x94
> [__alloc_pages+167/818] __alloc_pages+0xa7/0x332
> [<c0143516>] __alloc_pages+0xa7/0x332
> [__get_free_pages+34/69] __get_free_pages+0x22/0x45
> [<c01437c3>] __get_free_pages+0x22/0x45
This looks like mostly garbage from an attempt to handle a fault and
then blocking on mm->mmap_sem.
On Sun, Dec 07, 2003 at 01:06:34PM +0100, Alex Riesen wrote:
> [do_page_fault+0/1416] do_page_fault+0x0/0x588
> [<c011d6b1>] do_page_fault+0x0/0x588
> [error_code+45/56] error_code+0x2d/0x38
> [<c010aec1>] error_code+0x2d/0x38
> [do_mmap_pgoff+83/1656] do_mmap_pgoff+0x53/0x678
> [<c01511fc>] do_mmap_pgoff+0x53/0x678
> [pipe_read+516/628] pipe_read+0x204/0x274
> [<c016ac01>] pipe_read+0x204/0x274
> [sys_mmap2+155/210] sys_mmap2+0x9b/0xd2
> [<c01111a4>] sys_mmap2+0x9b/0xd2
> [syscall_call+7/11] syscall_call+0x7/0xb
> [<c010a437>] syscall_call+0x7/0xb
You took a fault in do_mmap_pgoff().
-- wli
===== mm/mmap.c 1.95 vs edited =====
--- 1.95/mm/mmap.c Sat Dec 6 14:34:36 2003
+++ edited/mm/mmap.c Sun Dec 7 04:17:04 2003
@@ -479,8 +479,10 @@
if (!file->f_op || !file->f_op->mmap)
return -ENODEV;
- if ((prot & PROT_EXEC) && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
- return -EPERM;
+ if (file->f_vfsmnt && (prot & PROT_EXEC)) {
+ if (file->f_vfsmnt->mnt_flags & MNT_NOEXEC)
+ return -EPERM;
+ }
}
if (!len)
-- wli
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] FIx 'noexec' behavior
@ 2003-12-07 12:06 Alex Riesen
2003-12-07 12:17 ` William Lee Irwin III
0 siblings, 1 reply; 12+ messages in thread
From: Alex Riesen @ 2003-12-07 12:06 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: linux-kernel, Andrew Morton, Jon Smirl
> Also, you can try running mozilla with strace -f. Redirect the strace
> output to a file with the -o option. Mozilla should work if you use an
> updated RHL9 or FC1 installation. This will show where the program
> tries to use mmap in a way conflicting with the patch.
I have a lot of processes frozen after applying the patch. I had not
enough patience to wait until any of them finish, but I have traces from
Alt+SysRq+T. Almost anything trying to access entries of /proc/<pid> is
frozen: ls /proc/[0-9]*/, top, killall, ps. Also the stack of mozilla
looks strange: 5a5a5a5a 5a5a5a5a...
start-stop-da D 00000001 0 16248 16229 (NOTLB)
f6967e14 00000082 c18d2c80 00000001 00000003 3fd310d6 3aee6e31 c02cce00
f6967df8 c01776aa f7ff7104 4014839e c02cce00 f7010ce0 c18d2c80 0014fa7d
631c5675 000002cf eb16b310 f4178b30 eb16b310 fffeffff f6967e34 c01bcd27
Call Trace:
[alloc_inode+30/337] alloc_inode+0x1e/0x151
[<c01776aa>] alloc_inode+0x1e/0x151
[rwsem_down_failed_common+157/342] rwsem_down_failed_common+0x9d/0x156
[<c01bcd27>] rwsem_down_failed_common+0x9d/0x156
[rwsem_down_read_failed+41/50] rwsem_down_read_failed+0x29/0x32
[<c01bca95>] rwsem_down_read_failed+0x29/0x32
[.text.lock.base+7/105] .text.lock.base+0x7/0x69
[<c018cad2>] .text.lock.base+0x7/0x69
[proc_pid_follow_link+104/128] proc_pid_follow_link+0x68/0x80
[<c018b102>] proc_pid_follow_link+0x68/0x80
[link_path_walk+1459/2479] link_path_walk+0x5b3/0x9af
[<c016c64e>] link_path_walk+0x5b3/0x9af
[kmem_cache_alloc+407/469] kmem_cache_alloc+0x197/0x1d5
[<c0147e7b>] kmem_cache_alloc+0x197/0x1d5
[__user_walk+64/85] __user_walk+0x40/0x55
[<c016cfa8>] __user_walk+0x40/0x55
[vfs_stat+30/85] vfs_stat+0x1e/0x55
[<c0167a88>] vfs_stat+0x1e/0x55
[sys_stat64+27/55] sys_stat64+0x1b/0x37
[<c0168173>] sys_stat64+0x1b/0x37
[syscall_call+7/11] syscall_call+0x7/0xb
[<c010a437>] syscall_call+0x7/0xb
ls D 00000001 0 1426 1 1094 1235 (NOTLB)
f0c87ed0 00200082 c18dac80 00000001 00000003 ebd7e000 f7ffd6b0 f0c87efc
c010ae26 80000800 ebd7e000 ec949740 f7f65718 f0c86000 c18dac80 000140f5
1e0176a7 00000181 eb965940 f4178b30 eb965940 fffeffff f0c87ef0 c01bcd27
Call Trace:
[apic_timer_interrupt+26/32] apic_timer_interrupt+0x1a/0x20
[<c010ae26>] apic_timer_interrupt+0x1a/0x20
[rwsem_down_failed_common+157/342] rwsem_down_failed_common+0x9d/0x156
[<c01bcd27>] rwsem_down_failed_common+0x9d/0x156
[dput+36/607] dput+0x24/0x25f
[<c0175453>] dput+0x24/0x25f
[rwsem_down_read_failed+41/50] rwsem_down_read_failed+0x29/0x32
[<c01bca95>] rwsem_down_read_failed+0x29/0x32
[.text.lock.base+7/105] .text.lock.base+0x7/0x69
[<c018cad2>] .text.lock.base+0x7/0x69
[proc_pid_readlink+139/306] proc_pid_readlink+0x8b/0x132
[<c018b268>] proc_pid_readlink+0x8b/0x132
[sys_readlink+136/140] sys_readlink+0x88/0x8c
[<c0168032>] sys_readlink+0x88/0x8c
[syscall_call+7/11] syscall_call+0x7/0xb
[<c010a437>] syscall_call+0x7/0xb
killall D 00000001 0 1393 1 1225 1205 (NOTLB)
e9e75dd8 00200082 c18d2c80 00000001 00000003 c1681730 c02cac00 000001f7
00104025 e9e75dec c0143516 c02cac00 00000000 00000000 c18d2c80 002f05a1
eae91d50 00000172 eb16a080 f4178b30 eb16a080 fffeffff e9e75df8 c01bcd27
Call Trace:
[__alloc_pages+167/818] __alloc_pages+0xa7/0x332
3516>] __alloc_pages+0xa7/0x332
[rwsem_down_failed_common+157/342] rwsem_down_failed_common+0x9d/0x156
[<c01bcd27>] rwsem_down_failed_common+0x9d/0x156
[rwsem_down_read_failed+41/50] rwsem_down_read_failed+0x29/0x32
[<c01bca95>] rwsem_down_read_failed+0x29/0x32
[.text.lock.array+43/143] .text.lock.array+0x2b/0x8f
[<c018e6e4>] .text.lock.array+0x2b/0x8f
[do_page_fault+861/1416] do_page_fault+0x35d/0x588
[<c011da0e>] do_page_fault+0x35d/0x588
[pid_revalidate+62/234] pid_revalidate+0x3e/0xea
[<c018b9be>] pid_revalidate+0x3e/0xea
[dput+36/607] dput+0x24/0x25f
[<c0175453>] dput+0x24/0x25f
[buffered_rmqueue+237/404] buffered_rmqueue+0xed/0x194
[<c01433c8>] buffered_rmqueue+0xed/0x194
[__alloc_pages+167/818] __alloc_pages+0xa7/0x332
[<c0143516>] __alloc_pages+0xa7/0x332
[proc_info_read+83/350] proc_info_read+0x53/0x15e
[<c018ad3d>] proc_info_read+0x53/0x15e
[vfs_read+161/268] vfs_read+0xa1/0x10c
[<c015dd49>] vfs_read+0xa1/0x10c
[sys_read+63/93] sys_read+0x3f/0x5d
[<c015dfb3>] sys_read+0x3f/0x5d
[syscall_call+7/11] syscall_call+0x7/0xb
[<c010a437>] syscall_call+0x7/0xb
ps D A4D7615A 0 1255 1 1235 1245 (NOTLB)
eba73dd8 00200086 eb3ec6b0 a4d7615a 0000013d 00000745 eb63d000 00000000
00ffffff c02917a0 2000007b a4d7615a 0000013d eb3ec6b0 c18d2c80 00061ae7
a4db7273 0000013d eb3ecce0 f4178b30 eb3ecce0 fffeffff eba73df8 c01bcd27
Call Trace:
[rwsem_down_failed_common+157/342] rwsem_down_failed_common+0x9d/0x156
[<c01bcd27>] rwsem_down_failed_common+0x9d/0x156
[rwsem_down_read_failed+41/50] rwsem_down_read_failed+0x29/0x32
[<c01bca95>] rwsem_down_read_failed+0x29/0x32
[.text.lock.array+43/143] .text.lock.array+0x2b/0x8f
[<c018e6e4>] .text.lock.array+0x2b/0x8f
[pty_write+463/465] pty_write+0x1cf/0x1d1
[<c01edb1b>] pty_write+0x1cf/0x1d1
[pid_revalidate+62/234] pid_revalidate+0x3e/0xea
[<c018b9be>] pid_revalidate+0x3e/0xea
[dput+36/607] dput+0x24/0x25f
[<c0175453>] dput+0x24/0x25f
[buffered_rmqueue+237/404] buffered_rmqueue+0xed/0x194
[<c01433c8>] buffered_rmqueue+0xed/0x194
[check_poison_obj+41/399] check_poison_obj+0x29/0x18f
[<c0145e89>] check_poison_obj+0x29/0x18f
[__alloc_pages+167/818] __alloc_pages+0xa7/0x332
[<c0143516>] __alloc_pages+0xa7/0x332
[proc_info_read+83/350] proc_info_read+0x53/0x15e
[<c018ad3d>] proc_info_read+0x53/0x15e
[filp_open+93/95] filp_open+0x5d/0x5f
[<c015ce85>] filp_open+0x5d/0x5f
[vfs_read+161/268] vfs_read+0xa1/0x10c
[<c015dd49>] vfs_read+0xa1/0x10c
[sys_read+63/93] sys_read+0x3f/0x5d
[<c015dfb3>] sys_read+0x3f/0x5d
[syscall_call+7/11] syscall_call+0x7/0xb
[<c010a437>] syscall_call+0x7/0xb
top D 00000001 0 1235 1 1426 1255 (NOTLB)
eb715dd8 00000082 c18dac80 00000001 00000003 eb715db8 c0145e89 eb67d4ec
0000016c eb715dc8 c0147d96 c0189d50 eb67d4ec eb67d4e8 c18dac80 004c5976
96f4de4f 00000134 eb965310 f4178b30 eb965310 fffeffff eb715df8 c01bcd27
Call Trace:
[check_poison_obj+41/399] check_poison_obj+0x29/0x18f
[<c0145e89>] check_poison_obj+0x29/0x18f
[kmem_cache_alloc+178/469] kmem_cache_alloc+0xb2/0x1d5
[<c0147d96>] kmem_cache_alloc+0xb2/0x1d5
[proc_alloc_inode+30/115] proc_alloc_inode+0x1e/0x73
[<c0189d50>] proc_alloc_inode+0x1e/0x73
[rwsem_down_failed_common+157/342] rwsem_down_failed_common+0x9d/0x156
[<c01bcd27>] rwsem_down_failed_common+0x9d/0x156
[proc_alloc_inode+77/115] proc_alloc_inode+0x4d/0x73
[<c0189d7f>] proc_alloc_inode+0x4d/0x73
[rwsem_down_read_failed+41/50] rwsem_down_read_failed+0x29/0x32
[<c01bca95>] rwsem_down_read_failed+0x29/0x32
[.text.lock.array+43/143] .text.lock.array+0x2b/0x8f
[<c018e6e4>] .text.lock.array+0x2b/0x8f
[proc_pident_lookup+246/588] proc_pident_lookup+0xf6/0x24c
[<c018c002>] proc_pident_lookup+0xf6/0x24c
[real_lookup+219/258] real_lookup+0xdb/0x102
[<c016bdf9>] real_lookup+0xdb/0x102
[dput+36/607] dput+0x24/0x25f
[<c0175453>] dput+0x24/0x25f
[buffered_rmqueue+237/404] buffered_rmqueue+0xed/0x194
[<c01433c8>] buffered_rmqueue+0xed/0x194
[check_poison_obj+41/399] check_poison_obj+0x29/0x18f
[<c0145e89>] check_poison_obj+0x29/0x18f
[__alloc_pages+167/818] __alloc_pages+0xa7/0x332
[<c0143516>] __alloc_pages+0xa7/0x332
[proc_info_read+83/350] proc_info_read+0x53/0x15e
[<c018ad3d>] proc_info_read+0x53/0x15e
[filp_open+93/95] filp_open+0x5d/0x5f
[<c015ce85>] filp_open+0x5d/0x5f
[vfs_read+161/268] vfs_read+0xa1/0x10c
[<c015dd49>] vfs_read+0xa1/0x10c
[sys_read+63/93] sys_read+0x3f/0x5d
[<c015dfb3>] sys_read+0x3f/0x5d
[syscall_call+7/11] syscall_call+0x7/0xb
[<c010a437>] syscall_call+0x7/0xb
mozilla-bin D 00000001 0 1225 1 1245 1393 (NOTLB)
eba79df4 00000082 c18dac80 00000001 00000003 5a5a5a5a 5a5a5a5a 5a5a5a5a
5a5a5a5a 5a5a5a5a 5a5a5a5a 5a5a5a5a 5a5a5a5a 5a5a5a5a c18dac80 00008714
65e68354 00000130 f6efd940 f689d4dc f6efd940 fffeffff eba79e14 c01bcd27
Call Trace:
[rwsem_down_failed_common+157/342] rwsem_down_failed_common+0x9d/0x156
[<c01bcd27>] rwsem_down_failed_common+0x9d/0x156
[do_page_fault+0/1416] do_page_fault+0x0/0x588
[<c011d6b1>] do_page_fault+0x0/0x588
[rwsem_down_read_failed+41/50] rwsem_down_read_failed+0x29/0x32
[<c01bca95>] rwsem_down_read_failed+0x29/0x32
[.text.lock.fault+27/131] .text.lock.fault+0x1b/0x83
[<c011dc54>] .text.lock.fault+0x1b/0x83
[buffered_rmqueue+237/404] buffered_rmqueue+0xed/0x194
[<c01433c8>] buffered_rmqueue+0xed/0x194
[pte_chain_alloc+143/148] pte_chain_alloc+0x8f/0x94
[<c015480b>] pte_chain_alloc+0x8f/0x94
[__alloc_pages+167/818] __alloc_pages+0xa7/0x332
[<c0143516>] __alloc_pages+0xa7/0x332
[__get_free_pages+34/69] __get_free_pages+0x22/0x45
[<c01437c3>] __get_free_pages+0x22/0x45
[do_page_fault+0/1416] do_page_fault+0x0/0x588
[<c011d6b1>] do_page_fault+0x0/0x588
[error_code+45/56] error_code+0x2d/0x38
[<c010aec1>] error_code+0x2d/0x38
[do_mmap_pgoff+83/1656] do_mmap_pgoff+0x53/0x678
[<c01511fc>] do_mmap_pgoff+0x53/0x678
[pipe_read+516/628] pipe_read+0x204/0x274
[<c016ac01>] pipe_read+0x204/0x274
[sys_mmap2+155/210] sys_mmap2+0x9b/0xd2
[<c01111a4>] sys_mmap2+0x9b/0xd2
[syscall_call+7/11] syscall_call+0x7/0xb
[<c010a437>] syscall_call+0x7/0xb
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] FIx 'noexec' behavior
2003-12-06 19:57 ` OGAWA Hirofumi
@ 2003-12-06 20:15 ` Jon Smirl
0 siblings, 0 replies; 12+ messages in thread
From: Jon Smirl @ 2003-12-06 20:15 UTC (permalink / raw)
To: OGAWA Hirofumi, Ulrich Drepper; +Cc: Jon Smirl, lkml
This seems to fix it:
[jonsmirl@smirl mm]$ bk diffs
===== mmap.c 1.94 vs edited =====
481c481
< if ((prot & PROT_EXEC) && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
---
> if (file && (prot & PROT_EXEC) && (file->f_vfsmnt->mnt_flags & MNT_NOEXE
C))
[jonsmirl@smirl mm]$
Although I didn't have any oops on my console, in dmesg or messages.
--- OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:
> Ulrich Drepper <drepper@redhat.com> writes:
>
> if (file && (!file->f_op || !file->f_op->mmap))
> return -ENODEV;
>
> if ((prot & PROT_EXEC) && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
> return -EPERM;
>
> Probably he get the oops, because file can be NULL.
> --
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] FIx 'noexec' behavior
[not found] <20031206200322.86264.qmail@web14902.mail.yahoo.com>
@ 2003-12-06 20:07 ` Ulrich Drepper
0 siblings, 0 replies; 12+ messages in thread
From: Ulrich Drepper @ 2003-12-06 20:07 UTC (permalink / raw)
To: Jon Smirl; +Cc: lkml
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jon Smirl wrote:
= 0
> 9292 old_mmap(0xbfe0f000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0[jonsmirl@smirl jonsmirl]$
Add "file && " to the beginning of the new conditional and it should work.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/0jcH2ijCOnn/RHQRAgs4AJ9xSCtZ27lM2hgmDJhW24atTPDHbgCcDWHQ
jfa75LhA4JGRuwBodslzB3A=
=A0T0
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] FIx 'noexec' behavior
2003-12-06 19:34 ` Ulrich Drepper
@ 2003-12-06 19:57 ` OGAWA Hirofumi
2003-12-06 20:15 ` Jon Smirl
0 siblings, 1 reply; 12+ messages in thread
From: OGAWA Hirofumi @ 2003-12-06 19:57 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: Jon Smirl, lkml
Ulrich Drepper <drepper@redhat.com> writes:
if (file && (!file->f_op || !file->f_op->mmap))
return -ENODEV;
if ((prot & PROT_EXEC) && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
return -EPERM;
Probably he get the oops, because file can be NULL.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] FIx 'noexec' behavior
2003-12-06 19:18 Jon Smirl
@ 2003-12-06 19:34 ` Ulrich Drepper
2003-12-06 19:57 ` OGAWA Hirofumi
0 siblings, 1 reply; 12+ messages in thread
From: Ulrich Drepper @ 2003-12-06 19:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: lkml
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jon Smirl wrote:
> /dev/sda5 / ext3 defaults 1 1
> /dev/sda1 /boot ext3 defaults 1 2
> LABEL=/dos /rh9 ext3 defaults 1 2
> /dev/sda2 swap swap defaults 0 0
> /dev/hda3 swap swap defaults 0 0
> /dev/cdrom /mnt/cdrom udf,iso9660
> noauto,owner,kudzu,ro 0 0
> /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
> none /sys sysfs defaults 0 0
> tmpfs /tmp tmpfs defaults,size=800M 0 0
> none /dev/pts devpts gid=5,mode=620 0 0
> none /proc proc defaults 0 0
> none /dev/shm tmpfs defaults 0 0
> /dev/md0 /home ext3 defaults 1 2
> /dev/cdrom1 /mnt/cdrom1 udf,iso9660
> noauto,owner,kudzu,ro 0 0
Unless one of the filesystems does something funny and sets the noexec
bit automatically, I see nothing which could cause the problem since
there is no "noexec" anywhere. Maybe you have additional mounts.
Instead of looking at fstab, send the output of running "mount" without
any parameter.
Also, you can try running mozilla with strace -f. Redirect the strace
output to a file with the -o option. Mozilla should work if you use an
updated RHL9 or FC1 installation. This will show where the program
tries to use mmap in a way conflicting with the patch.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/0i9d2ijCOnn/RHQRAhojAKC/PCc9Q7zStuglTS7jql9OOW65+gCeJkmm
7Dm7Kd72Sju/Km977wGFGxY=
=DGsA
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] FIx 'noexec' behavior
@ 2003-12-06 19:18 Jon Smirl
2003-12-06 19:34 ` Ulrich Drepper
0 siblings, 1 reply; 12+ messages in thread
From: Jon Smirl @ 2003-12-06 19:18 UTC (permalink / raw)
To: lkml
CC me on replies. I'm not subscribed.
Here's my fstab.
/dev/sda5 / ext3 defaults 1 1
/dev/sda1 /boot ext3 defaults 1 2
LABEL=/dos /rh9 ext3 defaults 1 2
/dev/sda2 swap swap defaults 0 0
/dev/hda3 swap swap defaults 0 0
/dev/cdrom /mnt/cdrom udf,iso9660
noauto,owner,kudzu,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
none /sys sysfs defaults 0 0
tmpfs /tmp tmpfs defaults,size=800M 0 0
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/md0 /home ext3 defaults 1 2
/dev/cdrom1 /mnt/cdrom1 udf,iso9660
noauto,owner,kudzu,ro 0 0
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] FIx 'noexec' behavior
2003-12-06 17:27 Jon Smirl
@ 2003-12-06 18:20 ` Ulrich Drepper
0 siblings, 0 replies; 12+ messages in thread
From: Ulrich Drepper @ 2003-12-06 18:20 UTC (permalink / raw)
To: Jon Smirl; +Cc: lkml
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jon Smirl wrote:
> This patch makes Mozilla fail to load on my system. If I back it out everything
> is fine again. No error messages, Mozilla just hangs for about thirty seconds
> and exits.
What do all the mounts on this system look like?
The changes in fact change the kernel ABI but any programs which has
problems with this is buggy and it either can easily be changed, or it
actively does something compromising the security of the system.
Anyway, stalling is the least I expect since the kernel returns a new
error. Unless, of course, there is another programming mistake in the
program's code.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/0h4J2ijCOnn/RHQRAhx7AJ4lUy5JcdE0bCwoKh6LMP0t/uOoMACgst4N
mnLPEmLg3SIBUDTVVYZlpfQ=
=sZ/A
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] FIx 'noexec' behavior
@ 2003-12-06 17:27 Jon Smirl
2003-12-06 18:20 ` Ulrich Drepper
0 siblings, 1 reply; 12+ messages in thread
From: Jon Smirl @ 2003-12-06 17:27 UTC (permalink / raw)
To: lkml
This patch makes Mozilla fail to load on my system. If I back it out everything
is fine again. No error messages, Mozilla just hangs for about thirty seconds
and exits.
CUPS also hangs at shutdown.
epiphany works both ways.
Running up2date Fedora and current 2.6 kernel.
P4, 2.8 HT, SMP enabled, ACPI
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-12-07 16:19 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-12-07 13:39 [PATCH] FIx 'noexec' behavior Alex Riesen
2003-12-07 13:42 ` William Lee Irwin III
2003-12-07 16:19 ` Alex Riesen
-- strict thread matches above, loose matches on Subject: below --
2003-12-07 12:06 Alex Riesen
2003-12-07 12:17 ` William Lee Irwin III
[not found] <20031206200322.86264.qmail@web14902.mail.yahoo.com>
2003-12-06 20:07 ` Ulrich Drepper
2003-12-06 19:18 Jon Smirl
2003-12-06 19:34 ` Ulrich Drepper
2003-12-06 19:57 ` OGAWA Hirofumi
2003-12-06 20:15 ` Jon Smirl
2003-12-06 17:27 Jon Smirl
2003-12-06 18:20 ` Ulrich Drepper
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).