08 Jul, 2011
3 commits
-
Unlike CCMP, the presence or absence of the QoS
field doesn't change the encryption, only the
TID is used. When no QoS field is present, zero
is used as the TID value. This means that it is
possible for an attacker to take a QoS packet
with TID 0 and replay it as a non-QoS packet.Unfortunately, mac80211 uses different IVs for
checking the validity of the packet's TKIP IV
when it checks TID 0 and when it checks non-QoS
packets. This means it is vulnerable to this
replay attack.To fix this, use the same replay counter for
TID 0 and non-QoS packets by overriding the
rx->queue value to 0 if it is 16 (non-QoS).This is a minimal fix for now. I caused this
issue incommit 1411f9b531f0a910cd1c85a337737c1e6ffbae6a
Author: Johannes Berg
Date: Thu Jul 10 10:11:02 2008 +0200mac80211: fix RX sequence number check
while fixing a sequence number issue (there,
a separate counter needs to be used).Cc: stable@kernel.org
Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
We were not allocating memory for the IEs passed in the scheduled_scan
request and this was causing memory corruption (buffer overflow).Signed-off-by: Luciano Coelho
Signed-off-by: John W. Linville -
Our workarounds seem to be clientmode PCI specific. Using SPROM
workaround on SoC resulted in Oops:Data bus error, epc == 8017ed58, ra == 80225838
Oops[#1]:
Cpu 0
$ 0 : 00000000 10008000 b8000000 00000001
$ 4 : 80293b5c 00000caa ffffffff 00000000
$ 8 : 0000000a 00000003 00000001 696d6d20
$12 : ffffffff 00000000 00000000 ffffffff
$16 : 802d0140 b8004800 802c0000 00000000
$20 : 00000000 802c0000 00000000 802d04d4
$24 : 00000018 80151a00
$28 : 81816000 81817df8 8029bda0 80225838
Hi : 00000000
Lo : 00000000
epc : 8017ed58 ssb_ssb_read16+0x48/0x60
Not tainted
ra : 80225838 ssb_pcicore_init+0x54/0x3b4Reported-by: Hauke Mehrtens
Signed-off-by: Rafał Miłecki
Tested-by: Hauke Mehrtens
Signed-off-by: John W. Linville
06 Jul, 2011
7 commits
-
Signed-off-by: Yoann DI-RUZZA
Signed-off-by: Larry Finger
Cc: Stable
Signed-off-by: John W. Linville -
While sending aggregated frames in AES, the AR5416 chips
required additional padding b/w subframes. This workaround
is not needed for edma (AR9003 family) chips. With this patch
~4Mbps thoughput improvement was observed in clear environment.Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan
Signed-off-by: John W. Linville -
Cc: stable@kernel.org
Reported-by: Mark Davis
Signed-off-by: Christian Lamparter
Signed-off-by: John W. Linville -
There was a deadlock when rfkill-blocking a wireless interface,
because we were locking the rdev mutex on NETDEV_GOING_DOWN to stop
sched_scans that were eventually running. The rfkill block code was
already holding a mutex under rdev:kernel: =======================================================
kernel: [ INFO: possible circular locking dependency detected ]
kernel: 3.0.0-rc1-00049-g1fa7b6a #57
kernel: -------------------------------------------------------
kernel: kworker/0:1/4525 is trying to acquire lock:
kernel: (&rdev->mtx){+.+.+.}, at: [] cfg80211_netdev_notifier_call+0x131/0x5b0
kernel:
kernel: but task is already holding lock:
kernel: (&rdev->devlist_mtx){+.+.+.}, at: [] cfg80211_rfkill_set_block+0x4f/0xa0
kernel:
kernel: which lock already depends on the new lock.To fix this, add a new mutex specifically for sched_scan, to protect
the sched_scan_req element in the rdev struct, instead of using the
global rdev mutex.Reported-by: Duane Griffin
Signed-off-by: Luciano Coelho
Signed-off-by: John W. Linville -
Signed-off-by: Pavel Roskin
Cc:
Signed-off-by: John W. Linville -
Signed-off-by: Pavel Roskin
Cc:
Signed-off-by: John W. Linville
01 Jul, 2011
3 commits
-
If the remote device is not present, the connections attemp fails and
the struct hci_conn was not freedSigned-off-by: Tomas Targownik
Signed-off-by: Gustavo F. Padovan -
PTS test A2DP/SRC/SRC_SET/TC_SRC_SET_BV_02_I revealed that
( probably after the df3c3931e commit ) the l2cap connection
could not be established in case when the "Auth Complete" HCI
event does not arive before the initiator send "Configuration
request", in which case l2cap replies with "Command rejected"
since the channel is still in BT_CONNECT2 state.Based on patch from: Ilia Kolomisnky
Signed-off-by: Gustavo F. Padovan
-
Partial revert of commit aabf6f89. When the hidp session thread
was converted from kernel_thread to kthread, the atomic/wakeups
were replaced with kthread_stop. kthread_stop has blocking semantics
which are inappropriate for the hidp session kthread. In addition,
the kthread signals itself to terminate in hidp_process_hid_control()
- it cannot do this with kthread_stop().Lastly, a wakeup can be lost if the wakeup happens between checking
for the loop exit condition and setting the current state to
TASK_INTERRUPTIBLE. (Without appropriate synchronization mechanisms,
the task state should not be changed between the condition test and
the yield - via schedule() - as this creates a race between the
wakeup and resetting the state back to interruptible.)Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan
30 Jun, 2011
2 commits
-
We would free the proper number of curves, but in the wrong
slots, due to a missing level of indirection through
the pdgain_idx table.It's simpler just to try to free all four slots, so do that.
Cc: stable@kernel.org
Signed-off-by: Bob Copeland
Signed-off-by: John W. Linville -
When no interface has been brought up, the chip's power
state continued as AWAKE. So during resume, the chip never
been powered up.Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan
Signed-off-by: John W. Linville
29 Jun, 2011
1 commit
-
A remote user can provide a small value for the command size field in
the command header of an l2cap configuration request, resulting in an
integer underflow when subtracting the size of the configuration request
header. This results in copying a very large amount of data via
memcpy() and destroying the kernel heap. Check for underflow.Signed-off-by: Dan Rosenberg
Cc: stable
Signed-off-by: Gustavo F. Padovan
28 Jun, 2011
4 commits
-
"iwlagn: map command buffers BIDI" uses the DMA_* enumerations for DMA
directions, even though the pci_* DMA API is still in use. That patch
was undoubtedly developed on top of "iwlagn: don't use the PCI wrappers
for DMA operation", which is due in the next release.Signed-off-by: John W. Linville
-
Sometimes when reporting a MIC failure rx->key may be unset. This
code path is hit when receiving a packet meant for a multicast
address, and decryption is performed in HW.Fortunately, the failing key_idx is not used for anything up to
(and including) usermode, so we allow ourselves to drop it on the
way up when a key cannot be retrieved.Signed-off-by: Arik Nemtsov
Cc: stable@kernel.org
Signed-off-by: John W. Linville -
Currently (3.0-rc2), modinfo iwlagn shows:
firmware: iwlwifi-5150-IWL5150_UCODE_API_MAX.ucode
firmware: iwlwifi-5000-IWL5000_UCODE_API_MAX.ucode
firmware: iwlwifi-6000g2b-IWL6000G2_UCODE_API_MAX.ucode
firmware: iwlwifi-6000g2a-IWL6000G2_UCODE_API_MAX.ucode
firmware: iwlwifi-6050-IWL6050_UCODE_API_MAX.ucode
firmware: iwlwifi-6000-IWL6000_UCODE_API_MAX.ucode
firmware: iwlwifi-100-IWL100_UCODE_API_MAX.ucode
firmware: iwlwifi-1000-IWL1000_UCODE_API_MAX.ucode
firmware: iwlwifi-105-IWL105_UCODE_API_MAX.ucode
firmware: iwlwifi-2030-IWL2030_UCODE_API_MAX.ucode
firmware: iwlwifi-2000-IWL2000_UCODE_API_MAX.ucodewhich is obviously wrong, the user should not see the *_UCODE_API_MAX
macros but the actual ucode API versions here.The problem are the
#define *_MODULE_FIRMWARE(api) *_FW_PRE #api ".ucode"
which do not expand api correctly (because this is a macro itself).Fixed by using __stringify() from linux/stringify.h.
Further information about macro stringification can be found here:
http://gcc.gnu.org/onlinedocs/cpp/Stringification.htmlSigned-off-by: Evgeni Golov
Signed-off-by: Wey-Yi Guy
Signed-off-by: John W. Linville
27 Jun, 2011
2 commits
-
Evidently, the device sometimes wants to write back
to command buffers, even if I see no reason why it
should. Allow it to do that.Tested-by: Andy Lutomirski
Tested-by: Kyle McMartin
Signed-off-by: Johannes Berg
Signed-off-by: Wey-Yi Guy -
When we stop the device while a command is in
flight that uses multiple TBs, we can leak the
DMA buffers for the second and higher TBs. Fix
this by using iwlagn_unmap_tfd() as we do when
we normally recover the entry.Signed-off-by: Johannes Berg
Signed-off-by: Wey-Yi Guy
25 Jun, 2011
2 commits
-
When an interface changes type to a P2P type,
iwlagn will erroneously set vif->type to the
P2P type and not the reduced/split type. Fix
this by keeping "newtype" in another variable
for the assignment to vif->type.Cc: stable@kernel.org [2.6.38+]
Signed-off-by: Johannes Berg
Signed-off-by: Wey-Yi Guy -
Since we don't have HUGE command any more, there is no point in adding 1
to the num of slots in the command queue. Doing so is buggy and might corrupt
memory.Bug introduced by 4ce7cc2b09553a91d4aea014c39674685715173a
iwlagn: support multiple TBs per commandCc: Johannes Berg
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Wey-Yi Guy
23 Jun, 2011
1 commit
-
In commit 3ac5e26a1e935469a8bdae1d624bc3b59d1fcdc5 entitled
"rtlwifi: rtl8192c-common: Change common firmware routines for addition
of rtl8192se and rtl8192de", the firmware loading code was moved.
Unfortunately, some necessary code was dropped for rtl8192cu.The dmesg output shows the following:
rtl8192c: Loading firmware file rtlwifi/rtl8192cufw.bin
rtl8192c_common:_rtl92c_fw_free_to_go(): Polling FW ready fail!! REG_MCUFWDL:0x00000006 .
rtl8192c_common:rtl92c_download_fw(): Firmware is not ready to run!In addition, the interface will authenticate and associate, but cannot
transfer data.This is reported as Kernel Bug #38012.
Signed-off-by: Larry Finger
Signed-off-by: John W. Linville
21 Jun, 2011
2 commits
-
There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and
RTL8192SE. The method of distinguishing them is by the revision ID
at offset 0x8 of the PCI configuration space. If the value is 0x10,
then the device uses rtl8192se for a driver.Signed-off-by: Larry Finger
Signed-off-by: John W. Linville
16 Jun, 2011
1 commit
-
In hci_conn_security ( which is used during L2CAP connection
establishment ) test for HCI_CONN_ENCRYPT_PEND state also
sets this state, which is bogus and leads to connection time-out
on L2CAP sockets in certain situations (especially when
using non-ssp devices )Signed-off-by: Ilia Kolomisnky
Signed-off-by: Gustavo F. Padovan
15 Jun, 2011
3 commits
-
Post commit e4eefec73ea0a740bfe8736e3ac30dfe92fe392b, the stack is
not generating the CCMP header for us anymore. This broke the CCMP
functionality since firmware was not doing this either. Set a flag
to tell the firmware to generate the CCMP headerSigned-off-by: Nishant Sarmukadam
Signed-off-by: John W. Linville -
Following OOPS was seen when booting with card inserted
BUG: unable to handle kernel NULL pointer dereference at 0000004c
IP: [] cfg80211_get_drvinfo+0x21/0x115 [cfg80211]
*pde = 00000000
Oops: 0000 [#1] SMP
Modules linked in: iwl3945 iwl_legacy mwifiex_sdio mac80211 11 sdhci_pci sdhci pl2303'ethtool' on the mwifiex device returned this OOPS as
wiphy_dev() returned NULL.Adding missing set_wiphy_dev() call to fix the problem.
Signed-off-by: Yogesh Ashok Powar
Signed-off-by: John W. Linville -
When authentication completes we shouldn't blindly accept any pending
L2CAP connect requests. If the socket has the defer_setup feature
enabled it should still wait for user space acceptance of the connect
request. The issue only happens for non-SSP connections since with SSP
the L2CAP Connect request may not be sent for non-SDP PSMs before
authentication has completed successfully.Signed-off-by: Johan Hedberg
Signed-off-by: Gustavo F. Padovan
14 Jun, 2011
1 commit
-
With older userspace versions (using hciops) it might not have the
key type to check if the key has sufficient security for any security
level so it is necessary to check the return of hci_conn_auth to make
sure the connection is authenticatedSigned-off-by: Luiz Augusto von Dentz
Acked-by: Johan Hedberg
Signed-off-by: Gustavo F. Padovan
11 Jun, 2011
4 commits
-
Some old hci controllers do not accept any mask so leave the
default mask on for these devices.< HCI Command: Set Event Mask (0x03|0x0001) plen 8
Mask: 0xfffffbff00000000
> HCI Event: Command Complete (0x0e) plen 4
Set Event Mask (0x03|0x0001) ncmd 1
status 0x12
Error: Invalid HCI Command ParametersSigned-off-by: Ville Tervo
Tested-by: Corey Boyle
Tested-by: Ed Tomlinson
Signed-off-by: Gustavo F. Padovan -
Signed-off-by: David S. Miller
Signed-off-by: Gustavo F. Padovan -
shutdown should wait for SCO link to be properly disconnected before
detroying the socket, otherwise an application using the socket may
assume link is properly disconnected before it really happens which
can be a problem when e.g synchronizing profile switch.Signed-off-by: Luiz Augusto von Dentz
Signed-off-by: Gustavo F. Padovan
10 Jun, 2011
1 commit
-
Structures "l2cap_conninfo" and "rfcomm_conninfo" have one padding
byte each. This byte in "cinfo" is copied to userspace uninitialized.Signed-off-by: Filip Palian
Acked-by: Marcel Holtmann
Signed-off-by: Gustavo F. Padovan
09 Jun, 2011
3 commits
-
We use priv->mutex to avoid race conditions between chswitch_done()
and mac_channel_switch(), when marking channel switch in
progress. But chswitch_done() can be called in atomic context
from rx_csa() or with mutex already taken from commit_rxon().To fix remove mutex from chswitch_done() and use atomic bitops
for marking channel switch pending.Cc: stable@kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville -
Ignacy reports that sometimes after leaving an IBSS
joining a new one didn't work because there still
were stations on the list. He fixed it by flushing
stations when attempting to join a new IBSS, but
this shouldn't be happening in the first case. When
I looked into it I saw a race condition in teardown
that could cause stations to be added after flush,
and thus cause this situation. Ignacy confirms that
after applying my patch he hasn't seen this happen
again.Reported-by: Ignacy Gawedzki
Debugged-by: Ignacy Gawedzki
Tested-by: Ignacy Gawedzki
Cc: stable@kernel.org
Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
During channge channel, tx power will not send to uCode, the tx power command
should send after scan complete. but should also can send after RXON command.Stable fix identified by Stanislaw Gruszka .
Signed-off-by: Wey-Yi Guy
Cc: stable@kernel.org [2.6.38+]
Signed-off-by: John W. Linville
