The first one fixes a smatch false positive and the second one fixes
a potential bug.
drivers/net/wireless/iwlwifi/iwl-5000.c +786 iwl5000_txq_update_byte_cnt_tbl(37) error: buffer overflow
'(scd_bc_tbl+txq_id)->tfd_offset' 320 <= 512
drivers/net/wireless/iwlwifi/iwl-5000.c +808 iwl5000_txq_inval_byte_cnt_tbl(19) error: buffer overflow
'(scd_bc_tbl+txq_id)->tfd_offset' 320 <= 512
Signed-off-by: Dan Carpenter <[email protected]>
Cc: [email protected]
---
I don't have the hardware to test this change.
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index de45f30..b45150d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -781,7 +781,7 @@ void iwl5000_txq_update_byte_cnt_tbl(struct iwl_priv *priv,
scd_bc_tbl[txq_id].tfd_offset[write_ptr] = bc_ent;
- if (txq->q.write_ptr < TFD_QUEUE_SIZE_BC_DUP)
+ if (write_ptr < TFD_QUEUE_SIZE_BC_DUP)
scd_bc_tbl[txq_id].
tfd_offset[TFD_QUEUE_SIZE_MAX + write_ptr] = bc_ent;
}
@@ -803,7 +803,7 @@ void iwl5000_txq_inval_byte_cnt_tbl(struct iwl_priv *priv,
bc_ent = cpu_to_le16(1 | (sta_id << 12));
scd_bc_tbl[txq_id].tfd_offset[read_ptr] = bc_ent;
- if (txq->q.write_ptr < TFD_QUEUE_SIZE_BC_DUP)
+ if (read_ptr < TFD_QUEUE_SIZE_BC_DUP)
scd_bc_tbl[txq_id].
tfd_offset[TFD_QUEUE_SIZE_MAX + read_ptr] = bc_ent;
}
On Thu, 2010-02-18 at 01:45 -0800, Dan Carpenter wrote:
> The first one fixes a smatch false positive and the second one fixes
> a potential bug.
>
> drivers/net/wireless/iwlwifi/iwl-5000.c +786 iwl5000_txq_update_byte_cnt_tbl(37) error: buffer overflow
> '(scd_bc_tbl+txq_id)->tfd_offset' 320 <= 512
> drivers/net/wireless/iwlwifi/iwl-5000.c +808 iwl5000_txq_inval_byte_cnt_tbl(19) error: buffer overflow
> '(scd_bc_tbl+txq_id)->tfd_offset' 320 <= 512
>
> Signed-off-by: Dan Carpenter <[email protected]>
> Cc: [email protected]
> ---
This has already been fixed by patch below (taken from
wireless-next-2.6). John and Greg, could you please pick this one up for
2.6.33 and stable instead?
commit 8ce1ef4a914aef8b9b90a2a2c670494168a2cca9
Author: Wey-Yi Guy <[email protected]>
Date: Fri Jan 8 10:04:44 2010 -0800
iwlwifi: fix bug in tx byte count table
When setting invalid byte count in txq byte count table, read
pointer
should be used instead of write pointer.
Reported-by: Guo, Chaohong <[email protected]>
Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: Zhu Yi <[email protected]>
Signed-off-by: Reinette Chatre <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Reinette
On Thu, Feb 18, 2010 at 10:04:42AM -0800, reinette chatre wrote:
> On Thu, 2010-02-18 at 01:45 -0800, Dan Carpenter wrote:
> > The first one fixes a smatch false positive and the second one fixes
> > a potential bug.
> >
> > drivers/net/wireless/iwlwifi/iwl-5000.c +786 iwl5000_txq_update_byte_cnt_tbl(37) error: buffer overflow
> > '(scd_bc_tbl+txq_id)->tfd_offset' 320 <= 512
> > drivers/net/wireless/iwlwifi/iwl-5000.c +808 iwl5000_txq_inval_byte_cnt_tbl(19) error: buffer overflow
> > '(scd_bc_tbl+txq_id)->tfd_offset' 320 <= 512
> >
> > Signed-off-by: Dan Carpenter <[email protected]>
> > Cc: [email protected]
> > ---
>
> This has already been fixed by patch below (taken from
> wireless-next-2.6). John and Greg, could you please pick this one up for
> 2.6.33 and stable instead?
>
> commit 8ce1ef4a914aef8b9b90a2a2c670494168a2cca9
> Author: Wey-Yi Guy <[email protected]>
> Date: Fri Jan 8 10:04:44 2010 -0800
>
> iwlwifi: fix bug in tx byte count table
>
> When setting invalid byte count in txq byte count table, read
> pointer
> should be used instead of write pointer.
>
> Reported-by: Guo, Chaohong <[email protected]>
> Signed-off-by: Wey-Yi Guy <[email protected]>
> Signed-off-by: Zhu Yi <[email protected]>
> Signed-off-by: Reinette Chatre <[email protected]>
> Signed-off-by: John W. Linville <[email protected]>
So for the record, that patch is basically identical to Dan's patch
but with some whitespace fixups in some nearby lines as well.
How important is this patch? Is there an actual bug report? Is it
a regression?
It is very late in the 2.6.33 cycle and it isn't obvious to me that
this is worth pushing for 2.6.33 at this point...?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Fri, 2010-02-19 at 12:30 -0800, John W. Linville wrote:
> So for the record, that patch is basically identical to Dan's patch
> but with some whitespace fixups in some nearby lines as well.
>
> How important is this patch? Is there an actual bug report? Is it
> a regression?
>
> It is very late in the 2.6.33 cycle and it isn't obvious to me that
> this is worth pushing for 2.6.33 at this point...?
This is exactly the reason why we did not post the patch to 2.6.33 or
stable when we submitted it upstream since there was no regression or
bug tied to it at that time. It surely is a problem that needs fixing,
which we did in the current release. I just highlighted that if there is
a request for this to be fixed in stable then we already have the patch
available. I'm ok with this one only going into 2.6.34.
Reinette