Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 78750 - /proc bad perms + kernel NULL pointer dereference
Summary: /proc bad perms + kernel NULL pointer dereference
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i686
OS: Linux
high
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-11-28 23:01 UTC by jonny robertson
Modified: 2007-03-27 03:58 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-02 17:58:27 UTC


Attachments (Terms of Use)

Description jonny robertson 2002-11-28 23:01:50 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18)
M$-Free/Gecko/20010110 Netscape6/6.5

Description of problem:
have discovered some interesting behaviour with my redhat 8.0 kernel.
this has been tested vs 2.4.18-14 and 2.4.18-18, on 2 seperate rh8 
installs on different hardware.

the majority of the files in the /proc/speakup/ directory have world 
writeable permissions on them.
this can be used to generate very interesting results on roots terminal if 
he decides to 'dmesg', after
a bunch of control characters have been spewed into the logs via echo to 
proc.

however, doing an echo "pretty much anything" > /proc/speakup/synth
causes the shell process you are coming from to segfault and exit, and 
prints this into the messages log:

Nov 28 19:20:36 pichu kernel:  <1>Unable to handle kernel NULL pointer 
dereference at virtual address 00000000
Nov 28 19:20:36 pichu kernel:  printing eip:
Nov 28 19:20:36 pichu kernel: c019b1d2
Nov 28 19:20:36 pichu kernel: *pde = 00000000
Nov 28 19:20:36 pichu kernel: Oops: 0000
Nov 28 19:20:36 pichu kernel: ide-cd cdrom i810_audio ac97_codec soundcore 
mousedev input autofs ds yenta_so
Nov 28 19:20:36 pichu kernel: CPU:    0
Nov 28 19:20:36 pichu kernel: EIP:    0010:[<c019b1d2>]    Not tainted
Nov 28 19:20:36 pichu kernel: EFLAGS: 00010246
Nov 28 19:20:36 pichu kernel:
Nov 28 19:20:36 pichu kernel: EIP is at speakup_synth_write_proc [kernel] 
0x82 (2.4.18-14)
Nov 28 19:20:36 pichu kernel: eax: 00000000   ebx: d016df60   ecx: 
d016df60   edx: fffffff2
Nov 28 19:20:36 pichu kernel: esi: d016df60   edi: ffffffea   ebp: 
00000001   esp: d016df50
Nov 28 19:20:36 pichu kernel: ds: 0018   es: 0018   ss: 0018
Nov 28 19:20:36 pichu kernel: Process bash (pid: 2651, stackpage=d016d000)
Nov 28 19:20:36 pichu kernel: Stack: d016df60 080e6c08 00000001 00000000 
00000000 c014e342 0000000a d5f1aae0
Nov 28 19:20:36 pichu kernel:        00000000 d050dae0 ffffffea 00000001 
c0162140 d050dae0 080e6c08 00000001
Nov 28 19:20:36 pichu kernel:        00000000 c013fd53 d050dae0 080e6c08 
00000001 d050db00 d016c000 00000007
Nov 28 19:20:36 pichu kernel: Call Trace: [<c014e342>] dupfd [kernel] 0x52 
(0xd016df64))
Nov 28 19:20:36 pichu kernel: [<c0162140>] proc_file_write [kernel] 0x40 
(0xd016df80))
Nov 28 19:20:36 pichu kernel: [<c013fd53>] sys_write [kernel] 0xa3 
(0xd016df94))
Nov 28 19:20:36 pichu kernel: [<c010910f>] system_call [kernel] 0x33 
(0xd016dfc0))
Nov 28 19:20:36 pichu kernel:
Nov 28 19:20:36 pichu kernel:
Nov 28 19:20:36 pichu kernel: Code: 8b 38 ac ae 75 08 84 c0 75 f8 31 c0 eb 
04 19 c0 0c 01 85 c0

i have no idea if the kernel can be subverted or DoS'd in any way as a 
result of this, but i will report it anyway as i was surprised to see o+w 
files in /proc.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. echo "whatever" > /proc/speakup/synth
2.
3.
	

Actual Results:  kernel NULL pointer dereference

Expected Results:  it should have rejected this value initially based on the
fact i was an unpriv user, and secondly on the input i was giving.

Additional info:

Comment 1 Michael Lee Yohe 2002-12-02 15:06:44 UTC
This is indeed a nasty bug.  You may want to attach a ksymoops output file to
this bug for any more information that it can provide.  Since a normal user can
cause system instability - severity should be HIGH.

Comment 2 Alan Cox 2002-12-18 18:38:50 UTC
Currently looking into it. Quick fix is to chmod that file to 0 during boot


Comment 3 Michael K. Johnson 2003-06-02 17:58:27 UTC
Was fixed quite some time ago by changing to have none of the files
have world-writeable permissions, we just forgot to mark this bug
report as closed.


Note You need to log in before you can comment on or make changes to this bug.