libubox/tests/cram, branch master

blobmsg_json: fix double format string to avoid truncation and data loss

2026-05-03T20:17:39Z

Using %lf (= %f) with the default precision of 6 fractional decimal digits requires up to 317 characters for negative values close to -DBL_MAX (1 sign + 309 integer digits + 1 decimal point + 6 fraction digits + NUL), but buf[] only holds 317 bytes, leaving no room for the NUL terminator — snprintf truncates the last digit silently. Additionally, 6 fractional digits do not give round-trip accuracy for IEEE 754 doubles; 17 significant digits (%.17g) are required. Switch to %.17g which uses scientific notation for very large or small values, keeping the output well within the buffer, and guarantees round-trip accuracy for all finite doubles. Update the cram fixtures test_blobmsg.t and test_blobmsg_types.t to match the new output. The previous fixtures encoded the buggy behaviour: DBL_MIN serialised as "0.000000" and was silently flattened to zero on the JSON round-trip, while DBL_MAX produced a 309-digit decimal string. Link: https://github.com/openwrt/libubox/pull/42 Co-Authored-By: Claude Sonnet 4.6 Signed-off-by: Hauke Mehrtens

tests: add blob-buffer overflow test

2021-04-29T13:34:21Z

The blob buffer has no limitation in place to prevent buflen to exceed maximum size. This commit adds a test to demonstrate how a blob increases past the maximum allowd size of 16MB. It continuously adds chunks of 64KB and with the 255th one blob_add() returns a valid attribute pointer but the blob's buflen does not increase. The test is used to demonstrate the failure, which is fixed with a follow-up commit. Signed-off-by: Zefir Kurtisi [adjusted test case for cram usage] Signed-off-by: Petr Štetiar

libubox: tests: add more blobmsg/json test cases

2021-03-09T20:53:14Z

* add mixed int/double tests * add blobmsg_cast_u64/blobmsg_cast_s64 tests Signed-off-by: Peter Seiderer

tests: cram: test_base64: really fix failing tests

2021-03-03T17:26:52Z

Remove the checks for 'Aborted (core dumped)' message altogether as it's not reliable and not portable. References: https://gitlab.com/openwrt/project/libubox/-/jobs/1070226897 Signed-off-by: Petr Štetiar

tests: cram: test_base64: fix failing tests

2021-03-03T13:37:09Z

Seems like latest version of llvm compiler/sanitizer has changed behaviour during crash so `Aborted (core dumped)` is now printed to stdout. Fixes following issue: --- /builds/openwrt/project/libubox/tests/cram/test_base64.t +++ /builds/openwrt/project/libubox/tests/cram/test_base64.t.err @@ -49,9 +49,7 @@ b64_encode: Assertion `dest && targsize > 0' failed. $ test-b64_decode-san 2> output.log; check - Aborted (core dumped) b64_decode: Assertion `dest && targsize > 0' failed. $ test-b64_encode-san 2> output.log; check - Aborted (core dumped) b64_encode: Assertion `dest && targsize > 0' failed. References: https://gitlab.com/openwrt/project/libubox/-/jobs/1069840314 Signed-off-by: Petr Štetiar

tests: add fuzzer seed file for crash in blob_len

2020-05-26T07:48:07Z

Following regression was introduced in commit 5e75160f4878 ("blobmsg: fix attrs iteration in the blobmsg_check_array_len()"): Thread 1 "test-fuzz" received signal SIGSEGV, Segmentation fault. in blob_len (attr=0x6020000100d4) at libubox/blob.h:102 102 return (be32_to_cpu(attr->id_len) & BLOB_ATTR_LEN_MASK) - sizeof(struct blob_attr); blob_len (attr=0x6020000100d4) at /libubox/blob.h:102 blob_raw_len (attr=0x6020000100d4) at /libubox/blob.h:111 blob_pad_len (attr=0x6020000100d4) at /libubox/blob.h:120 blobmsg_check_array_len (attr=0x6020000000d0, type=0, blob_len=10) at /libubox/blobmsg.c:145 fuzz_blobmsg_parse (data=0x6020000000d0 "\001\004", size=10) at /libubox/tests/fuzz/test-fuzz.c:57 Signed-off-by: Petr Štetiar

blob: make blob_parse_untrusted more permissive

2020-05-24T14:54:37Z

Some tools like ucert use concatenations of multiple blobs. Account for this case by allowing the underlying buffer length to be greater than the blob length. Signed-off-by: Matthias Schiffer

libubox: runqueue: fix use-after-free bug

2020-05-21T13:58:46Z

Fixes a use-after-free bug in runqueue_task_kill(): Invalid read of size 8 at runqueue_task_kill (runqueue.c:200) by uloop_process_timeouts (uloop.c:505) by uloop_run_timeout (uloop.c:542) by uloop_run (uloop.h:111) by main (tests/test-runqueue.c:126) Address 0x5a4b058 is 24 bytes inside a block of size 208 free'd at free by runqueue_task_complete (runqueue.c:234) by runqueue_task_kill (runqueue.c:199) by uloop_process_timeouts (uloop.c:505) by uloop_run_timeout (uloop.c:542) by uloop_run (uloop.h:111) by main (tests/test-runqueue.c:126) Block was alloc'd at at calloc by add_sleeper (tests/test-runqueue.c:101) by main (tests/test-runqueue.c:123) Since commit 11e8afea (runqueue should call the complete handler from more places) the call to the complete() callback has been moved to runqueue_task_complete(). However in runqueue_task_kill() runqueue_task_complete() is called before the kill() callback. This will result in a use after free if the complete() callback frees the task struct. Furthermore runqueue_start_next() is already called at the end of runqueue_task_complete(), so there is no need to call it again in runqueue_task_kill(). The issue was that the _complete() callback frees the memory used by the task struct, which is then read after the _complete() callback returns. Ref: FS#3016 Signed-off-by: Alban Bedel [initial test case, kill cb comment fix] Signed-off-by: Chris Nisbet [testcase improvements and commit subject/description tweaks] Signed-off-by: Petr Štetiar

tests: list: add test case for list_empty iterator

2020-05-21T11:43:00Z

Increasing unit testing code coverage. Signed-off-by: Petr Štetiar

tests: blobmsg: add test case

2020-02-27T20:56:20Z

* add a test for blobmsg_check_array() to test an array with a string in it This test was added in conjunction with a change to blobmsg_check_array() to get it to pass the length obtained from blob_len() rather than blobmsg_len(). Signed-off-by: Chris Nisbet