2019-12-10 11:51:43 +01:00
|
|
|
check that blobmsg_parse is producing expected results:
|
|
|
|
|
|
|
|
|
|
$ [ -n "$TEST_BIN_DIR" ] && export PATH="$TEST_BIN_DIR:$PATH"
|
|
|
|
|
$ export FUZZ_CORPUS="$TESTDIR/../fuzz/corpus"
|
|
|
|
|
|
|
|
|
|
$ for blob in $(LC_ALL=C find $FUZZ_CORPUS -type f | sort ); do
|
|
|
|
|
> valgrind --quiet --leak-check=full test-blobmsg-parse $blob; \
|
|
|
|
|
> test-blobmsg-parse-san $blob; \
|
|
|
|
|
> done
|
|
|
|
|
71520a5c4b5ca73903216857abbad54a8002d44a: blobmsg_parse: ... (0)
|
|
|
|
|
71520a5c4b5ca73903216857abbad54a8002d44a: blobmsg_parse_array: ... (0)
|
|
|
|
|
71520a5c4b5ca73903216857abbad54a8002d44a: blobmsg_parse: ... (0)
|
|
|
|
|
71520a5c4b5ca73903216857abbad54a8002d44a: blobmsg_parse_array: ... (0)
|
|
|
|
|
c1dfd96eea8cc2b62785275bca38ac261256e278: blobmsg_parse: ... (0)
|
|
|
|
|
c1dfd96eea8cc2b62785275bca38ac261256e278: blobmsg_parse_array: ... (0)
|
|
|
|
|
c1dfd96eea8cc2b62785275bca38ac261256e278: blobmsg_parse: ... (0)
|
|
|
|
|
c1dfd96eea8cc2b62785275bca38ac261256e278: blobmsg_parse_array: ... (0)
|
|
|
|
|
c42ac1c46f1d4e211c735cc7dfad4ff8391110e9: blobmsg_parse: ... (0)
|
|
|
|
|
c42ac1c46f1d4e211c735cc7dfad4ff8391110e9: blobmsg_parse_array: ... (0)
|
|
|
|
|
c42ac1c46f1d4e211c735cc7dfad4ff8391110e9: blobmsg_parse: ... (0)
|
|
|
|
|
c42ac1c46f1d4e211c735cc7dfad4ff8391110e9: blobmsg_parse_array: ... (0)
|
|
|
|
|
crash-1b8fb1be45db3aff7699100f497fb74138f3df4f: blobmsg_parse: ... (0)
|
|
|
|
|
crash-1b8fb1be45db3aff7699100f497fb74138f3df4f: blobmsg_parse_array: ... (0)
|
|
|
|
|
crash-1b8fb1be45db3aff7699100f497fb74138f3df4f: blobmsg_parse: ... (0)
|
|
|
|
|
crash-1b8fb1be45db3aff7699100f497fb74138f3df4f: blobmsg_parse_array: ... (0)
|
|
|
|
|
crash-333757b203a44751d3535f24b05f467183a96d09: blobmsg_parse: ... (0)
|
|
|
|
|
crash-333757b203a44751d3535f24b05f467183a96d09: blobmsg_parse_array: ... (0)
|
|
|
|
|
crash-333757b203a44751d3535f24b05f467183a96d09: blobmsg_parse: ... (0)
|
|
|
|
|
crash-333757b203a44751d3535f24b05f467183a96d09: blobmsg_parse_array: ... (0)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-4c4d2c3c9ade5da9347534e290305c3b9760f627: blobmsg_parse: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-4c4d2c3c9ade5da9347534e290305c3b9760f627: blobmsg_parse_array: ... (-1)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-4c4d2c3c9ade5da9347534e290305c3b9760f627: blobmsg_parse: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-4c4d2c3c9ade5da9347534e290305c3b9760f627: blobmsg_parse_array: ... (-1)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-5e9937b197c88bf4e7b7ee2612456cad4cb83f5b: blobmsg_parse: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-5e9937b197c88bf4e7b7ee2612456cad4cb83f5b: blobmsg_parse_array: ... (-1)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-5e9937b197c88bf4e7b7ee2612456cad4cb83f5b: blobmsg_parse: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-5e9937b197c88bf4e7b7ee2612456cad4cb83f5b: blobmsg_parse_array: ... (-1)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-75b146c4e6fac64d3e62236b27c64b50657bab2a: blobmsg_parse: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-75b146c4e6fac64d3e62236b27c64b50657bab2a: blobmsg_parse_array: ... (-1)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-75b146c4e6fac64d3e62236b27c64b50657bab2a: blobmsg_parse: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-75b146c4e6fac64d3e62236b27c64b50657bab2a: blobmsg_parse_array: ... (-1)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-813f3e68661da09c26d4a87dbb9d5099e92be50f: blobmsg_parse: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-813f3e68661da09c26d4a87dbb9d5099e92be50f: blobmsg_parse_array: ... (-1)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-813f3e68661da09c26d4a87dbb9d5099e92be50f: blobmsg_parse: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-813f3e68661da09c26d4a87dbb9d5099e92be50f: blobmsg_parse_array: ... (-1)
|
|
|
|
|
crash-98595faa58ba01d85ba4fd0b109cd3d490b45795: blobmsg_parse: ... (0)
|
|
|
|
|
crash-98595faa58ba01d85ba4fd0b109cd3d490b45795: blobmsg_parse_array: ... (0)
|
|
|
|
|
crash-98595faa58ba01d85ba4fd0b109cd3d490b45795: blobmsg_parse: ... (0)
|
|
|
|
|
crash-98595faa58ba01d85ba4fd0b109cd3d490b45795: blobmsg_parse_array: ... (0)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-a3585b70f1c7ffbdec10f6dadc964336118485c4: blobmsg_parse: ... (-1)
|
|
|
|
|
crash-a3585b70f1c7ffbdec10f6dadc964336118485c4: blobmsg_parse_array: ... (-1)
|
|
|
|
|
crash-a3585b70f1c7ffbdec10f6dadc964336118485c4: blobmsg_parse: ... (-1)
|
|
|
|
|
crash-a3585b70f1c7ffbdec10f6dadc964336118485c4: blobmsg_parse_array: ... (-1)
|
|
|
|
|
crash-b3585b70f1c7ffbdec10f6dadc964336118485c4: blobmsg_parse: ... (-1)
|
|
|
|
|
crash-b3585b70f1c7ffbdec10f6dadc964336118485c4: blobmsg_parse_array: ... (-1)
|
|
|
|
|
crash-b3585b70f1c7ffbdec10f6dadc964336118485c4: blobmsg_parse: ... (-1)
|
|
|
|
|
crash-b3585b70f1c7ffbdec10f6dadc964336118485c4: blobmsg_parse_array: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-d0f3aa7d60a094b021f635d4edb7807c055a4ea1: blobmsg_parse: ... (0)
|
|
|
|
|
crash-d0f3aa7d60a094b021f635d4edb7807c055a4ea1: blobmsg_parse_array: ... (0)
|
|
|
|
|
crash-d0f3aa7d60a094b021f635d4edb7807c055a4ea1: blobmsg_parse: ... (0)
|
|
|
|
|
crash-d0f3aa7d60a094b021f635d4edb7807c055a4ea1: blobmsg_parse_array: ... (0)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-df9d1243057b27bbad6211e5a23d1cb699028aa2: blobmsg_parse: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-df9d1243057b27bbad6211e5a23d1cb699028aa2: blobmsg_parse_array: ... (0)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-df9d1243057b27bbad6211e5a23d1cb699028aa2: blobmsg_parse: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-df9d1243057b27bbad6211e5a23d1cb699028aa2: blobmsg_parse_array: ... (0)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-e2fd5ecb3b37926743256f1083f47a07c39e10c2: blobmsg_parse: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-e2fd5ecb3b37926743256f1083f47a07c39e10c2: blobmsg_parse_array: ... (-1)
|
blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov <luka.perkov@sartura.hr>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>
[refactored some checks, added fuzz inputs, adjusted unit test results]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
2020-01-12 12:26:18 +01:00
|
|
|
crash-e2fd5ecb3b37926743256f1083f47a07c39e10c2: blobmsg_parse: ... (-1)
|
2019-12-10 11:51:43 +01:00
|
|
|
crash-e2fd5ecb3b37926743256f1083f47a07c39e10c2: blobmsg_parse_array: ... (-1)
|
|
|
|
|
valid-blobmsg.bin: blobmsg_parse: MLT (0)
|
|
|
|
|
valid-blobmsg.bin: blobmsg_parse_array: MLT (0)
|
|
|
|
|
valid-blobmsg.bin: blobmsg_parse: MLT (0)
|
|
|
|
|
valid-blobmsg.bin: blobmsg_parse_array: MLT (0)
|
