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
Embargoed:


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.