Bugtraq mailing list archives

Re: Hot fix for do_brk bug


From: canon () nersc gov
Date: Tue, 09 Dec 2003 11:59:44 -0800


I had a similar approach working, but was still tweaking the implementation.  You beat
me to the punch.  Doh!  My working version did an objdump of vmlinux to determine the 
opcode boundaries.

One potential flaw in this approach is the instructions that are 
over-written by the jump and copied to the assembler routine (dobrk2)
can't include any operations that have relative addresses or offsets.
Fortunately, this seems quite rare from a brief scan of various kernel
routines.  However, its probably worth checking the assembler routine
before issuing the module load.  I still think this is a better approach than
my initial version that "fixed" calls and jumps.

Nice work.

--Shane



It would be less intrusive to the kernel to supply a fixed do_brk()
and replace the do_brk with a jump to your version.

I've written similar patch few days ago. The patch only modifies first
instructions of do_brk() (it replaces them with jmp to function in LKM.
It can be downloaded from http://wizard.ath.cx/fixbrk.tar.gz

But beware, I wrote it in rush and it's pretty odly written :-) But it
worked on my two servers (both were running 2.4.21 kernel with grsecurity
patch).

Greetings

Pavel Palát

--
Pavel "harry_x" Palát
    harry_x () babylon5 cz
    irc: #mistral.cz on IRCnet

    The only way of finding the limits to the possible is by going beyond them to the impossible
                                                  Arthur C. Clark


------------------------------------------------------------------------
Shane Canon                             voice: 510-486-6981
PSDF Project Lead                       fax:   510-486-7520
National Energy Research Scientific
  Computing Center
1 Cyclotron Road Mailstop 943-256
Berkeley, CA 94720                      canon () nersc gov
------------------------------------------------------------------------




Current thread: