1. 27 Jul, 2007 2 commits
    • Chuck Ebbert's avatar
      AGP: document boot options · c99c108a
      Chuck Ebbert authored
      Add documentation for AGP boot options.
      Signed-off-by: default avatarChuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      c99c108a
    • Jesper Juhl's avatar
      Fix "use after free" / "double free" bug in ati_create_gatt_pages / ati_free_gatt_pages · 190644e1
      Jesper Juhl authored
      Hi,
      
      Coverity spotted a "use after free" bug in
      drivers/char/agp/ati-agp.c::ati_create_gatt_pages().
      
      The same one that was in
        drivers/char/agp/amd-k7-agp.c::amd_create_gatt_pages()
      
      The problem is this:
             If "entry = kzalloc(sizeof(struct ati_page_map), GFP_KERNEL);"
      fails, then there's a loop in the function to free all entries
      allocated so far and break out of the allocation loop. That in itself
      is pretty sane, but then the (now freed) 'tables' is assigned to
      ati_generic_private.gatt_pages and 'retval' is set to -ENOMEM which
      causes ati_free_gatt_pages(); to be called at the end of the function.
      The problem with this is that ati_free_gatt_pages() will then loop
      'ati_generic_private.num_tables' times and try to free each entry in
      tables[] - this is bad since tables has already been freed and
      furthermore it will call kfree(tables) at the end - a double free.
      
      This patch removes the freeing loop in ati_create_gatt_pages() and
      instead relies entirely on the call to ati_free_gatt_pages() to free
      everything we allocated in case of an error. It also sets
      ati_generic_private.num_tables to the actual number of entries
      allocated instead of just using the value passed in from the caller -
      this ensures that ati_free_gatt_pages() will only attempt to free
      stuff that was actually allocated.
      
      Note: I'm in no way intimate with this code and I have no way to
      actually test this patch (besides compile test it), so while I've
      tried to be careful in reading the code and make sure the patch
      does the right thing an ACK from someone who actually knows the
      code in-depth would be very much appreciated.
      Signed-off-by: default avatarJesper Juhl <jesper.juhl@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@linux.ie>
      190644e1
  2. 26 Jul, 2007 38 commits