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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 16 Jan 2007 21:31:40 -0500
From:	Brandon Craig Rhodes <brandon@...desmill.org>
To:	netdev@...r.kernel.org
Subject: TKIP encryption should allocate enough tailroom

After frustrating days of hung TCP connections, I have determined that
the encryption routines in net/iee80211/ieee80211_crypt_tkip.c should
be more aggressive in providing themselves with enough packet tailroom
to perform their encryption.

They presently will only perform encryption if the packet handed to
them happens to be stored with enough tailroom already; otherwise,
they drop the packet.  If ieee80211_michael_mic_add() does not find
the eight bytes of tailroom it needs, it produces a message like

 kernel: Invalid packet for Michael MIC add (tailroom=6 hdr_len=24 skb->len=92)

and drops the packet.  The ieee80211_tkip_encrypt() function that
follows is less needy, requiring only four bytes of tailroom - but
fails to log anything at all when it drops a packet!

The attached patch, if applied to kernel 2.6.18, solves both problems.
I am not very familiar with the conventions of kernel networking code,
so there may be better ways of fixing this; but the patch should
illustrate the general idea, and perhaps provides others in my unhappy
situation with stable WPA connections until someone can provide a more
authorized patch.

And thanks for all the great code, guys; this is the first problem I
have had with the networking stack in eleven years of using Linux.


View attachment "ieee80211-tkip-tailroom.patch" of type "text/x-diff" (1376 bytes)


-- 
Brandon Craig Rhodes   brandon@...desmill.org   http://rhodesmill.org/brandon

Powered by blists - more mailing lists