On Thu, Jun 27, 2013 at 9:11 PM, <Valdis.Kletnieks@xxxxxx> wrote:
thanks Prasad, Mulyadi, Valdis
(ath6kl_deliver_frames_to_nw_stack+0xac/0xf0 [ath6kl_core])
with the arm gdb, am able to find the exact line and based on the test engineers
inputs, found the fix for crash.
seems fuzzy testing sends a destination mac address as zero, while we initialize
the list with mac address as zero, and memcmp returns a pointer, which inturn de-references
to an uninitialized pointer.
On Thu, 27 Jun 2013 18:29:48 +0700, Mulyadi Santosa said:
> On Thu, Jun 27, 2013 at 1:23 PM, Mohammed Shafi <shafi.kernel@xxxxxxxxx> wrote:
> > [ 486.447220] [<c000de98>] (__dabt_svc+0x38/0x60) from [<bf05c324>]
> If you find that name through grepping kernel source tree, you shallTo be more specific, the function is 0x60 (decimal 96) bytes long,
> find the culprit. The next number "0x38/0x60" AFAIK is the offset that
> shall point you to more exact location
and the pointer is at 0x38 (decimal 56) bytes into it. So even without
a disassembly, you know its somewhere between 1/2 and 2/3 of the way
through the code.
thanks Prasad, Mulyadi, Valdis
(ath6kl_deliver_frames_to_nw_stack+0xac/0xf0 [ath6kl_core])
with the arm gdb, am able to find the exact line and based on the test engineers
inputs, found the fix for crash.
seems fuzzy testing sends a destination mac address as zero, while we initialize
the list with mac address as zero, and memcmp returns a pointer, which inturn de-references
to an uninitialized pointer.
below is the fix :-)
|
| » if (is_zero_ether_addr(node_addr)) | 66 | ||
| » » return NULL; |
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
