lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 22 Apr 2012 09:45:55 +0800
From:	Huajun Li <huajun.li.lee@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	tom.leiming@...il.com, oneukum@...e.de, stern@...land.harvard.edu,
	davej@...hat.com, netdev@...r.kernel.org,
	linux-usb@...r.kernel.org, kernel-team@...oraproject.org
Subject: Re: use-after-free in usbnet

On Sun, Apr 22, 2012 at 3:23 AM, David Miller <davem@...emloft.net> wrote:
> From: Ming Lei <tom.leiming@...il.com>
> Date: Sat, 21 Apr 2012 09:49:51 +0800
>
>> I see the problem, so looks skb_queue_walk_safe is not safe.
>> I don' know why the 2nd ' tmp = skb->next' in  skb_queue_walk_safe
>> is needed and it may become unsafe if skb is freed during current loop.
>
> I can't see what the problem is, skb_queue_walk_safe() is perfect
> and does exactly what it advertises to do.
>
> If 'skb' is unlinked inside of an skb_queue_walk_safe() loop, that's
> fine, because we won't touch 'skb' in the loop iteration tail code.
>
> Instead, before the loop contents, we pre-fetch skb->next into 'tmp'
> and then at the end we move 'skb' forward by simply assigning 'tmp'.

In this case, the problem is, 'tmp = skb->next' can be moved out of
rxq/txq, and even be freed. Then in next loop cycle, 'skb = tmp' will
refer to a freed skb.  You know, in current code stack, unlink_urbs()
releases q->lock in each loop, this gives chance to urb complete
handler to call defer_bh() and cause the problem.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ