When parsing the EAPoL-Key key data field we don't strip the 0xdd /
0x00 padding from the decrypted data so there may be trailing padding
after the IE sequence and valgrind will report an invalid read of the
length byte. Same thing may happen if we're sent garbage.
Currently it supports Microsoft vendor specific information element
with version and type value 1 only. Typically it contains WPA security
related information.
==20758== Invalid read of size 1
==20758== at 0x401254: ie_tlv_iter_next (ie.c:55)
==20758== by 0x40104B: ie_test (test-ie.c:57)
==20758== by 0x4021C0: l_test_run (test.c:83)
==20758== by 0x4011B7: main (test-ie.c:123)
==20758== Address 0x51e10f3 is 0 bytes after a block of size 19 alloc'd
==20758== at 0x4C2C874: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20758== by 0x4010CF: append_data (test-ie.c:101)
==20758== by 0x40118F: main (test-ie.c:119)
==20758==
==20758== Invalid read of size 1
==20758== at 0x401266: ie_tlv_iter_next (ie.c:56)
==20758== by 0x40104B: ie_test (test-ie.c:57)
==20758== by 0x4021C0: l_test_run (test.c:83)
==20758== by 0x4011B7: main (test-ie.c:123)
==20758== Address 0x51e10f4 is 1 bytes after a block of size 19 alloc'd
==20758== at 0x4C2C874: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20758== by 0x4010CF: append_data (test-ie.c:101)
==20758== by 0x40118F: main (test-ie.c:119)