qed: potential overflow in qed_cxt_src_t2_alloc()
PATCH 1/1 qed: potential overflow in qed_cxt_src_t2_alloc()
In the current code "ent_per_page" could be more than "conn_num" making "conn_num" negative after the subtraction. In the next iteration through the loop then the negative is treated as a very high positive meaning we don't put a limit on "ent_num". It could lead to memory corruption.
drivers/net/ethernet/qlogic/qed/qed_cxt.c +1 -1
@@ -850,7 +850,7 @@ static int qed_cxt_src_t2_alloc(struct qed_hwfn *p_hwfn) val =0 ; entries[j].next =cpu_to_be64 (val); - conn_num -= ent_per_page; + conn_num -= ent_num; }return 0 ;
Quoted 7 lines
In the current code "
ent_per_page" could be more than "conn_num" making "conn_num" negative after the subtraction. In the next iteration through the loop then the negative is treated as a very high positive meaning we don't put a limit on "ent_num". It could lead to memory corruption.Fixes dbb799c39717 ('qed: Initialize hardware for new protocols')Signed-off-by Dan Carpenter <[email protected]>
I don't think we can actually hit an issue here, since the number of iterations was also calculated based on conn_num, so this can only happen on the last iteration.
Regardless, yours is the correct way to go. Thanks, Yuval.
From: Dan Carpenter <[email protected]>
Date: Tue, 7 Jun 2016 15:04:16 +0300
Quoted 8 lines
In the current code "
ent_per_page" could be more than "conn_num" making "conn_num" negative after the subtraction. In the next iteration through the loop then the negative is treated as a very high positive meaning we don't put a limit on "ent_num". It could lead to memory corruption.Fixes dbb799c39717 ('qed: Initialize hardware for new protocols')Signed-off-by Dan Carpenter <[email protected]>
Applied, thanks.