Skip to content

L
linux
Switch branch/tag
  1. 14 Feb, 2011 2 commits
    • Jesper Juhl's avatar
      Net, USB, Option, hso: Do not dereference NULL pointer · 5b89db0e
      Jesper Juhl authored 
      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: default avatarJesper Juhl <jj@chaosbits.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b89db0e
    • David S. Miller's avatar
      hisax: Fix unchecked alloc_skb() return. · c978e7bb
      David S. Miller authored 
      Jesper Juhl noticed that l2_pull_iqueue() does not
check to see if alloc_skb() fails.

Fix this by first trying to reallocate the headroom
if necessary, rather than later after we've made hard
to undo state changes.
Reported-by: default avatarJesper Juhl <jj@chaosbits.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c978e7bb
  3. 13 Feb, 2011 3 commits
  5. 12 Feb, 2011 3 commits
    • Herbert Xu's avatar
      bridge: Replace mp->mglist hlist with a bool · 8a870178
      Herbert Xu authored 
      As it turns out we never need to walk through the list of multicast
groups subscribed by the bridge interface itself (the only time we'd
want to do that is when we shut down the bridge, in which case we
simply walk through all multicast groups), we don't really need to
keep an hlist for mp->mglist.

This means that we can replace it with just a single bit to indicate
whether the bridge interface is subscribed to a group.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a870178
    • Herbert Xu's avatar
      bridge: Fix timer typo that may render snooping less effective · 24f9cdcb
      Herbert Xu authored 
      In a couple of spots where we are supposed to modify the port
group timer (p->timer) we instead modify the bridge interface
group timer (mp->timer).

The effect of this is mostly harmless.  However, it can cause
port subscriptions to be longer than they should be, thus making
snooping less effective.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24f9cdcb
    • Herbert Xu's avatar
      bridge: Fix mglist corruption that leads to memory corruption · 6b0d6a9b
      Herbert Xu authored 
      The list mp->mglist is used to indicate whether a multicast group
is active on the bridge interface itself as opposed to one of the
constituent interfaces in the bridge.

Unfortunately the operation that adds the mp->mglist node to the
list neglected to check whether it has already been added.  This
leads to list corruption in the form of nodes pointing to itself.

Normally this would be quite obvious as it would cause an infinite
loop when walking the list.  However, as this list is never actually
walked (which means that we don't really need it, I'll get rid of
it in a subsequent patch), this instead is hidden until we perform
a delete operation on the affected nodes.

As the same node may now be pointed to by more than one node, the
delete operations can then cause modification of freed memory.

This was observed in practice to cause corruption in 512-byte slabs,
most commonly leading to crashes in jbd2.

Thanks to Josef Bacik for pointing me in the right direction.
Reported-by: default avatarIan Page Hands <ihands@redhat.com>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b0d6a9b
  7. 11 Feb, 2011 3 commits
  9. 10 Feb, 2011 3 commits
  11. 09 Feb, 2011 8 commits
  13. 08 Feb, 2011 14 commits
  15. 07 Feb, 2011 4 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7