summaryrefslogtreecommitdiff
path: root/fs/quota_v1.c
diff options
context:
space:
mode:
authorJohn W. Linville <linville@tuxdriver.com>2007-10-10 14:12:57 +0400
committerGreg Kroah-Hartman <gregkh@suse.de>2007-11-02 18:44:09 +0300
commit1902ababc2188dea47d5677869fdd43c88490923 (patch)
treece5f6354ecf830a8f145809d74682101b8ffcdb8 /fs/quota_v1.c
parentfda485207e705c4447d450155e9b4eb85acf8062 (diff)
downloadlinux-1902ababc2188dea47d5677869fdd43c88490923.tar.xz
Fix ieee80211 handling of bogus hdrlength field
changeset 04045f98e0457aba7d4e6736f37eed189c48a5f7 from mainline Reported by Chris Evans <scarybeasts@gmail.com>: > The summary is that an evil 80211 frame can crash out a victim's > machine. It only applies to drivers using the 80211 wireless code, and > only then to certain drivers (and even then depends on a card's > firmware not dropping a dubious packet). I must confess I'm not > keeping track of Linux wireless support, and the different protocol > stacks etc. > > Details are as follows: > > ieee80211_rx() does not explicitly check that "skb->len >= hdrlen". > There are other skb->len checks, but not enough to prevent a subtle > off-by-two error if the frame has the IEEE80211_STYPE_QOS_DATA flag > set. > > This leads to integer underflow and crash here: > > if (frag != 0) > flen -= hdrlen; > > (flen is subsequently used as a memcpy length parameter). How about this? Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'fs/quota_v1.c')
0 files changed, 0 insertions, 0 deletions