Brian Szymanski discovered  a bug in  insmod that would  require a
    lot of time and luck to exploit, but is nonetheless important  for
    systems  wanting  rock-solid  security  (security  shouldn't  be a
    matter of luck).  In short,  when insmod is called without a  full
    path to the  module to load,  it checks a  small path to  find the
    module  in  question.   By  default,  this  path  is  the  current
    directory followed by the /lib/modules/ hierarchy.  In the  widely
    distributed versions of  the software, the  module is not  checked
    for root ownership,  and there is  no way to  tell which file  has
    been loaded after  insmod is called.   Needless to say,  putting a
    malicious user's  code in  to the  kernel and  then running  it in
    kernel mode is a very Bad Thing.

    The  new  version  (see  solution)  is  a big improvement, but not
    perfect  (after  all,  it's  a  pre-stable  version...)   The root
    ownership checks only appear to happen when the path to the module
    is not specified.  Is there any reason why you would ever need  to
    load a  module owned  by a  user, when  you can  just su  and copy
    /chown  it.   Also,  there  is  some  oddness  when  a  module  in
    /lib/modules isn't  owned by  root. insmod  spits out  24(!) lines
    like this:

        insmod: /lib/modules/2.2.4/misc/vmmon is not owned by root

    As previously mentioned,  an exploit would  require a lot  of luck
    and time, but would basically consist of regularly throwing a  lot
    of trojan'd .o  files in /tmp,  and waiting until  root decides to
    clean out tmp right before loading some module... Far-fetched  but
    too possible for comfort. Other scenarios along these lines  could
    be imagined.  Equally far fetched, but the point is the  currently
    distributed versions don't do it the Right Way... It's a lot  more
    likely that you would make your system crash and burn due to  this
    bug (although  files do  seem to  be checked  to be  in elf format
    before being loaded).


    The listed maintainer of the program, Jacques Gelinas informs that
    modprobe  (not  insmod)  should  be  used to load pathless modules
    from the /lib/modules heirarchy, but in practice most people  (and
    precanned  scripts)  use  insmod,  compounding  the  problem.   It
    appears that  the well  distributed versions  of modprobe  are NOT
    vulnerable  to  these  bugs  (tested  on  debian 2.1).  Change any
    documentation you write or scripts you distribute to use  modprobe
    instead of insmod.  The  versions included in debian, redhat,  and
    most if not all other  distributions are vulnerable as well.   Any
    version previous to 2.2.2-pre6 available from

    Please upgrade to this version.