Re: [ath9k-devel] smatch stuff: potential read past the end of the buffer
On Mon, Dec 20, 2010 at 02:00:41PM +0530, Dan Carpenter wrote:
Hello Vasanthakumar,
Smatch complains that in linux-next 60e0c3a7 ath9k_hw: Eeeprom changes
for AR9485 means there is a potential read past the end of the buffer
int ar9300_eeprom_restore_internal().
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c +3381
ar9300_eeprom_restore_internal(81)
error: buffer overflow 'word' 2048 = 4099
word is allocated with 2048 bytes:
word = kzalloc(2048, GFP_KERNEL);
length can be up to 4099:
if ((!AR_SREV_9485(ah) length = 1024) ||
(AR_SREV_9485(ah) length = (4 * 1024))) {
^
so osize can be up to 4099 as well:
osize = length;
We're reading way past the end of the word array here:
mchecksum = word[COMP_HDR_LEN + osize] |
^^
(word[COMP_HDR_LEN + osize + 1] 8);
I don't know how to fix this. Can you take a look?
thanks for pointing this out. we shall look into this.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] smatch stuff: potential read past the end of the buffer
Hi Dan,
Why not use min() function?
index = min(COMP_HDR_LEN + osize, 2046);
mchecksum = word[index] |
(word[index + 1] 8);
Or would smatch miss this in its analysis?
Gr. AvS
From: linux-wireless-ow...@vger.kernel.org
[linux-wireless-ow...@vger.kernel.org] On Behalf Of Dan Carpenter
[erro...@gmail.com]
Sent: Monday, December 20, 2010 9:30 AM
To: Vasanthakumar Thiagarajan
Cc: linux-wirel...@vger.kernel.org; ath9k-devel@lists.ath9k.org
Subject: smatch stuff: potential read past the end of the buffer
Hello Vasanthakumar,
Smatch complains that in linux-next 60e0c3a7 ath9k_hw: Eeeprom changes
for AR9485 means there is a potential read past the end of the buffer
int ar9300_eeprom_restore_internal().
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c +3381
ar9300_eeprom_restore_internal(81)
error: buffer overflow 'word' 2048 = 4099
word is allocated with 2048 bytes:
word = kzalloc(2048, GFP_KERNEL);
length can be up to 4099:
if ((!AR_SREV_9485(ah) length = 1024) ||
(AR_SREV_9485(ah) length = (4 * 1024))) {
^
so osize can be up to 4099 as well:
osize = length;
We're reading way past the end of the word array here:
mchecksum = word[COMP_HDR_LEN + osize] |
^^
(word[COMP_HDR_LEN + osize + 1] 8);
I don't know how to fix this. Can you take a look?
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] smatch stuff: potential read past the end of the buffer
Hi Dan, Agreed. But maybe there is no usage scenario in which the boundary is actually crossed. Have to wait for ath9k developers to answer that. Gr. AvS From: Dan Carpenter [erro...@gmail.com] Sent: Monday, December 20, 2010 1:42 PM To: Arend Van Spriel Cc: Vasanthakumar Thiagarajan; linux-wirel...@vger.kernel.org; ath9k-devel@lists.ath9k.org Subject: Re: smatch stuff: potential read past the end of the buffer On Mon, Dec 20, 2010 at 02:16:56AM -0800, Arend Van Spriel wrote: Hi Dan, Why not use min() function? index = min(COMP_HDR_LEN + osize, 2046); mchecksum = word[index] | (word[index + 1] 8); Or would smatch miss this in its analysis? That would silence the warning, but is it the right fix? I thought maybe we should make word a larger buffer? regards, dan carpenter ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ar9223 with caldata on flash (no eeprom) under openwrt
En/na Adrian Chadd ha escrit: I think a large part of the problem here is that the focus of the active technical developers is elsewhere. Where? You should see what trouble I've had getting questions answered here for the pre-AR9200 stuff. :-) Eg, trying to figure out the above - I have no idea. 10% of expected performance is pretty low, but is it a hardware poking problem, or is it a wifi configuration problem? How do you know, for example, that all of the board PCI/interrupt stuff is setup right? Well, I don't, I just hope that it is so. Are there any other PCI devices that are working at the correct throughput? IIRC the wifi chip is the only device on PCI (but I could be wrong, I'll double check when I can). The fact the PCI IDs are different may also be of interest. Have you done some digging to try and establish why that is the case? Most probably because the device has no internal eeprom. Apparently the ar71xx platform had the same kind of problem, fixed by poking some registers with the data from the flash, but I don't have any ar71xx device to test, I just inferred that from the openwrt code (hence my original question) Finally, is there any vendor-supplied code for this board? No, the board originally uses a propietary os with no documentation (and much less sources) available (in fact they went out of their way to obfuscate the original firmware in order to make it difficult to load alternatives), however 1) from the log messages it seems it's using ath9k (i.e. the messages are exactly the same as the ones I found in ath9k sources) 2) even the original firmware identifies it as ff1d, but then it sees it as 0029 (just like after the pci fixup I copied from the ar71xx but with the endianness problem I asked about). Bye -- Luca ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [patch -next] ath9k: unlock on error path in ath9k_change_interface()
There is a missing unlock when we hit the No beacon slot available
error condition.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index cb53fbb..0ffa115 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1481,6 +1481,7 @@ static int ath9k_change_interface(struct ieee80211_hw *hw,
struct ath_wiphy *aphy = hw-priv;
struct ath_softc *sc = aphy-sc;
struct ath_common *common = ath9k_hw_common(sc-sc_ah);
+ int ret = 0;
ath_dbg(common, ATH_DBG_CONFIG, Change Interface\n);
mutex_lock(sc-mutex);
@@ -1490,7 +1491,8 @@ static int ath9k_change_interface(struct ieee80211_hw *hw,
case NL80211_IFTYPE_ADHOC:
if (sc-nbcnvifs = ATH_BCBUF) {
ath_err(common, No beacon slot available\n);
- return -ENOBUFS;
+ ret = -ENOBUFS;
+ goto out;
}
break;
case NL80211_IFTYPE_STATION:
@@ -1504,14 +1506,15 @@ static int ath9k_change_interface(struct ieee80211_hw
*hw,
default:
ath_err(common, Interface type %d not yet supported\n,
vif-type);
- mutex_unlock(sc-mutex);
- return -ENOTSUPP;
+ ret = -ENOTSUPP;
+ goto out;
}
vif-type = new_type;
vif-p2p = p2p;
+out:
mutex_unlock(sc-mutex);
- return 0;
+ return ret;
}
static void ath9k_remove_interface(struct ieee80211_hw *hw,
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] BUG?
Mr. Mohammed Thank you for the reply. I'm sorry. It had been forgotten to apply ath9k-devel@lists.ath9k.org to cc in mail last time. It examined it. compat-wireless-2010-02-15 - OK compat-wireless-2010-02-20 - NG The recent correction only added rateidx by the ath_beacon_setup function of beacon.c. After it returns to the house, rateidx is corrected to 0 and the source of compat-wireless-2010-12-20 is tested. It tries though it is thought that it is a mistake perhaps to make to 0 only whether to be able to connect it for the time being. Sincerely yours By the way, I am not good at English. Sorry, Masahiro ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] smatch stuff: potential read past the end of the buffer
On Mon, Dec 20, 2010 at 02:00:41PM +0530, Dan Carpenter wrote:
Hello Vasanthakumar,
Smatch complains that in linux-next 60e0c3a7 ath9k_hw: Eeeprom changes
for AR9485 means there is a potential read past the end of the buffer
int ar9300_eeprom_restore_internal().
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c +3381
ar9300_eeprom_restore_internal(81)
error: buffer overflow 'word' 2048 = 4099
word is allocated with 2048 bytes:
word = kzalloc(2048, GFP_KERNEL);
length can be up to 4099:
if ((!AR_SREV_9485(ah) length = 1024) ||
(AR_SREV_9485(ah) length = (4 * 1024))) {
Yeah, this looks buggy, the eeprom data length for AR9485 is 1088
bytes only, I'll send out a patch, thanks for reporting this.
Vasanth
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] BUG?
In the hostapd config file hostapd.conf can you please try with hw_mode=b and hw_mode=g Also can you please send your configuration file of hostapd. thanks, shafi On Tue, Dec 21, 2010 at 10:10 AM, Masahiro Inoue miyabi.-.in...@nifty.com wrote: Mr. Mohammed Thank you for the reply. I'm sorry. It had been forgotten to apply ath9k-devel@lists.ath9k.org to cc in mail last time. It examined it. compat-wireless-2010-02-15 - OK compat-wireless-2010-02-20 - NG The recent correction only added rateidx by the ath_beacon_setup function of beacon.c. After it returns to the house, rateidx is corrected to 0 and the source of compat-wireless-2010-12-20 is tested. It tries though it is thought that it is a mistake perhaps to make to 0 only whether to be able to connect it for the time being. Sincerely yours By the way, I am not good at English. Sorry, Masahiro ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
