From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, Jouni Malinen <j@w1.fi>,
Johannes Berg <johannes.berg@intel.com>
Subject: [PATCH 3.4 03/25] mac80211: fix fragmentation code, particularly for encryption
Date: Thu, 20 Feb 2014 15:51:19 -0800 [thread overview]
Message-ID: <20140220234842.580678666@linuxfoundation.org> (raw)
In-Reply-To: <20140220234842.483343851@linuxfoundation.org>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <johannes.berg@intel.com>
commit 338f977f4eb441e69bb9a46eaa0ac715c931a67f upstream.
The "new" fragmentation code (since my rewrite almost 5 years ago)
erroneously sets skb->len rather than using skb_trim() to adjust
the length of the first fragment after copying out all the others.
This leaves the skb tail pointer pointing to after where the data
originally ended, and thus causes the encryption MIC to be written
at that point, rather than where it belongs: immediately after the
data.
The impact of this is that if software encryption is done, then
a) encryption doesn't work for the first fragment, the connection
becomes unusable as the first fragment will never be properly
verified at the receiver, the MIC is practically guaranteed to
be wrong
b) we leak up to 8 bytes of plaintext (!) of the packet out into
the air
This is only mitigated by the fact that many devices are capable
of doing encryption in hardware, in which case this can't happen
as the tail pointer is irrelevant in that case. Additionally,
fragmentation is not used very frequently and would normally have
to be configured manually.
Fix this by using skb_trim() properly.
Fixes: 2de8e0d999b8 ("mac80211: rewrite fragmentation")
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -907,7 +907,7 @@ static int ieee80211_fragment(struct iee
}
/* adjust first fragment's length */
- skb->len = hdrlen + per_fragm;
+ skb_trim(skb, hdrlen + per_fragm);
return 0;
}
next prev parent reply other threads:[~2014-02-20 23:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-20 23:51 [PATCH 3.4 00/25] 3.4.82-stable review Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 01/25] xen-blkfront: handle backend CLOSED without CLOSING Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 02/25] fs/file.c:fdtable: avoid triggering OOMs from alloc_fdmem Greg Kroah-Hartman
2014-02-20 23:51 ` Greg Kroah-Hartman [this message]
2014-02-20 23:51 ` [PATCH 3.4 04/25] s390/dump: Fix dump memory detection Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 05/25] s390: fix kernel crash due to linkage stack instructions Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 06/25] spi: Fix crash with double message finalisation on error handling Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 07/25] raw: test against runtime value of max_raw_minors Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 08/25] lockd: send correct lock when granting a delayed lock Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 09/25] tty: n_gsm: Fix for modems with brk in modem status control Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 10/25] staging:iio:ad799x fix error_free_irq which was freeing an irq that may not have been requested Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 12/25] USB: ftdi_sio: add Tagsys RFID Reader IDs Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 13/25] usb-storage: add unusual-devs entry for BlackBerry 9000 Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 14/25] usb-storage: restrict bcdDevice range for Super Top in Cypress ATACB Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 15/25] usb-storage: enable multi-LUN scanning when needed Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 16/25] usb: option: blacklist ZTE MF667 net interface Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 17/25] Modpost: fixed USB alias generation for ranges including 0x9 and 0xA Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 18/25] block: add cond_resched() to potentially long running ioctl discard loop Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 19/25] IB/qib: Add missing serdes init sequence Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 20/25] KVM: return an error code in kvm_vm_ioctl_register_coalesced_mmio() Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 21/25] md/raid5: Fix CPU hotplug callback registration Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 22/25] time: Fix overflow when HZ is smaller than 60 Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 23/25] power: max17040: Fix NULL pointer dereference when there is no platform_data Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 24/25] ring-buffer: Fix first commit on sub-buffer having non-zero delta Greg Kroah-Hartman
2014-02-20 23:51 ` [PATCH 3.4 25/25] genirq: Add missing irq_to_desc export for CONFIG_SPARSE_IRQ=n Greg Kroah-Hartman
2014-02-21 5:05 ` [PATCH 3.4 00/25] 3.4.82-stable review Guenter Roeck
2014-02-21 23:40 ` Shuah Khan
2014-02-22 20:45 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140220234842.580678666@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=j@w1.fi \
--cc=johannes.berg@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).