1. 09 7月, 2011 1 次提交
    • G
      hso: fix a use after free condition · 5e2cd082
      Greg KH 提交于
      This needs to go to netdev:
      
      From: Octavian Purdila <octavian.purdila@intel.com>
      
      In hso_free_net_device hso_net pointer is freed and then used to
      cleanup urb pools. Catched with SLAB_DEBUG during S3 resume:
      
      [   95.824442] Pid: 389, comm: khubd Tainted: G         C  2.6.36greenridge-01400-g423cf13-dirty #154 Type2 - Board Product Name1/OakTrail
      [   95.824442] EIP: 0060:[<c1151551>] EFLAGS: 00010202 CPU: 0
      [   95.824442] EIP is at kref_put+0x29/0x42
      [   95.824442] EAX: 6b6b6b6b EBX: 6b6b6b6b ECX: c2806b40 EDX: 00000037
      [   95.824442] ESI: c1258d56 EDI: edd3d128 EBP: ee8cde0c ESP: ee8cde04
      [   95.824442]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      [   95.824442] Process khubd (pid: 389, ti=ee8cc000 task=ee95ed10 task.ti=ee8cc000)
      [   95.824442] Stack:
      [   95.824442]  edd07020 00000000 ee8cde14 c1258b77 ee8cde38 ef933a44 ef93572b ef935dec
      [   95.824442] <0> 0000099a 6b6b6b6b 00000000 ee2da748 edd3e0c0 ee8cde54 ef933b9f ee3b53f8
      [   95.824442] <0> 00000002 ee2da748 ee2da764 ef936658 ee8cde60 ef933d0c ee2da748 ee8cde84
      [   95.824442] Call Trace:
      [   95.824442]  [<c1258b77>] ? usb_free_urb+0x11/0x13
      [   95.824442]  [<ef933a44>] ? hso_free_net_device+0x81/0xd8 [hso]
      [   95.824442]  [<ef933b9f>] ? hso_free_interface+0x104/0x111 [hso]
      [   95.824442]  [<ef933d0c>] ? hso_disconnect+0xb/0x18 [hso]
      [   95.824442]  [<c125b7f1>] ? usb_unbind_interface+0x44/0x14a
      [   95.824442]  [<c11e56e8>] ? __device_release_driver+0x6f/0xb1
      [   95.824442]  [<c11e57c7>] ? device_release_driver+0x18/0x23
      [   95.824442]  [<c11e4e92>] ? bus_remove_device+0x8a/0xa1
      [   95.824442]  [<c11e3970>] ? device_del+0x129/0x163
      [   95.824442]  [<c11e2dc0>] ? put_device+0xf/0x11
      [   95.824442]  [<c11e39bc>] ? device_unregister+0x12/0x15
      [   95.824442]  [<c125915f>] ? usb_disable_device+0x90/0xf0
      [   95.824442]  [<c125544f>] ? usb_disconnect+0x6d/0xf8
      [   95.824442]  [<c1255f91>] ? hub_thread+0x3fc/0xc57
      [   95.824442]  [<c1048526>] ? autoremove_wake_function+0x0/0x2f
      [   95.824442]  [<c102529d>] ? complete+0x34/0x3e
      [   95.824442]  [<c1255b95>] ? hub_thread+0x0/0xc57
      [   95.824442]  [<c10481fc>] ? kthread+0x63/0x68
      [   95.824442]  [<c1048199>] ? kthread+0x0/0x68
      [   95.824442]  [<c1002d76>] ? kernel_thread_helper+0x6/0x10
      Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5e2cd082
  2. 18 2月, 2011 3 次提交
  3. 14 2月, 2011 1 次提交
    • J
      Net, USB, Option, hso: Do not dereference NULL pointer · 5b89db0e
      Jesper Juhl 提交于
      In drivers/net/usb/hso.c::hso_create_bulk_serial_device() we have this
      code:
      ...
      	serial = kzalloc(sizeof(*serial), GFP_KERNEL);
      	if (!serial)
      		goto exit;
      ...
      exit:
      	hso_free_tiomget(serial);
      ...
      hso_free_tiomget() directly dereferences its argument, which in the
      example above is a NULL pointer, ouch.
      I could just add a 'if (serial)' test at the 'exit' label, but since most
      freeing functions in the kernel accept NULL pointers (and it seems like
      this was also assumed here) I opted to instead change 'hso_free_tiomget()'
      so that it is safe to call it with a NULL argument. I also modified the
      function to get rid of a pointles conditional before the call to
      'usb_free_urb()' since that function already tests for NULL itself -
      besides fixing the NULL deref this change also buys us a few bytes in
      size.
      Before:
      $ size drivers/net/usb/hso.o
         text    data     bss     dec     hex filename
        32200     592    9960   42752    a700 drivers/net/usb/hso.o
      After:
      $ size drivers/net/usb/hso.o
         text    data     bss     dec     hex filename
        32196     592    9960   42748    a6fc drivers/net/usb/hso.o
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b89db0e
  4. 21 12月, 2010 1 次提交
  5. 10 12月, 2010 1 次提交
  6. 29 11月, 2010 1 次提交
  7. 16 11月, 2010 1 次提交
  8. 23 10月, 2010 1 次提交
  9. 17 9月, 2010 1 次提交
  10. 17 8月, 2010 1 次提交
  11. 04 8月, 2010 1 次提交
  12. 13 7月, 2010 1 次提交
  13. 23 6月, 2010 1 次提交
  14. 03 6月, 2010 1 次提交
  15. 26 5月, 2010 1 次提交
  16. 14 5月, 2010 1 次提交
    • J
      drivers/net: Remove unnecessary returns from void function()s · a4b77097
      Joe Perches 提交于
      This patch removes from drivers/net/ all the unnecessary
      return; statements that precede the last closing brace of
      void functions.
      
      It does not remove the returns that are immediately
      preceded by a label as gcc doesn't like that.
      
      It also does not remove null void functions with return.
      
      Done via:
      $ grep -rP --include=*.[ch] -l "return;\n}" net/ | \
        xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }'
      
      with some cleanups by hand.
      
      Compile tested x86 allmodconfig only.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4b77097
  17. 10 5月, 2010 1 次提交
  18. 16 3月, 2010 1 次提交
  19. 07 1月, 2010 6 次提交
  20. 04 12月, 2009 1 次提交
  21. 24 11月, 2009 2 次提交
  22. 12 9月, 2009 1 次提交
    • M
      net: Add DEVTYPE support for Ethernet based devices · 384912ed
      Marcel Holtmann 提交于
      The Ethernet framing is used for a lot of devices these days. Most
      prominent are WiFi and WiMAX based devices. However for userspace
      application it is important to classify these devices correctly and
      not only see them as Ethernet devices. The daemons like HAL, DeviceKit
      or even NetworkManager with udev support tries to do the classification
      in userspace with a lot trickery and extra system calls. This is not
      good and actually reaches its limitations. Especially since the kernel
      does know the type of the Ethernet device it is pretty stupid.
      
      To solve this problem the underlying device type needs to be set and
      then the value will be exported as DEVTYPE via uevents and available
      within udev.
      
        # cat /sys/class/net/wlan0/uevent
        DEVTYPE=wlan
        INTERFACE=wlan0
        IFINDEX=5
      
      This is similar to subsystems like USB and SCSI that distinguish
      between hosts, devices, disks, partitions etc.
      
      The new SET_NETDEV_DEVTYPE() is a convenience helper to set the actual
      device type. All device types are free form, but for convenience the
      same strings as used with RFKILL are choosen.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      384912ed
  23. 02 9月, 2009 1 次提交
  24. 01 9月, 2009 1 次提交
  25. 06 7月, 2009 1 次提交
  26. 13 6月, 2009 1 次提交
  27. 08 6月, 2009 1 次提交
  28. 04 6月, 2009 1 次提交
    • J
      rfkill: rewrite · 19d337df
      Johannes Berg 提交于
      This patch completely rewrites the rfkill core to address
      the following deficiencies:
      
       * all rfkill drivers need to implement polling where necessary
         rather than having one central implementation
      
       * updating the rfkill state cannot be done from arbitrary
         contexts, forcing drivers to use schedule_work and requiring
         lots of code
      
       * rfkill drivers need to keep track of soft/hard blocked
         internally -- the core should do this
      
       * the rfkill API has many unexpected quirks, for example being
         asymmetric wrt. alloc/free and register/unregister
      
       * rfkill can call back into a driver from within a function the
         driver called -- this is prone to deadlocks and generally
         should be avoided
      
       * rfkill-input pointlessly is a separate module
      
       * drivers need to #ifdef rfkill functions (unless they want to
         depend on or select RFKILL) -- rfkill should provide inlines
         that do nothing if it isn't compiled in
      
       * the rfkill structure is not opaque -- drivers need to initialise
         it correctly (lots of sanity checking code required) -- instead
         force drivers to pass the right variables to rfkill_alloc()
      
       * the documentation is hard to read because it always assumes the
         reader is completely clueless and contains way TOO MANY CAPS
      
       * the rfkill code needlessly uses a lot of locks and atomic
         operations in locked sections
      
       * fix LED trigger to actually change the LED when the radio state
         changes -- this wasn't done before
      Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      19d337df
  29. 02 5月, 2009 1 次提交
  30. 23 4月, 2009 1 次提交
  31. 03 4月, 2009 2 次提交