libubox, branch master

md5: detect read errors in md5sum() instead of returning a bogus hash

2026-05-03T20:18:04Z

fread() returning 0 was treated as end of file, but it can also mean a read error. In that case the loop terminated and md5_end() ran on the partial data, so the caller received a md5 sum that did not correspond to the file content and no error was reported. Distinguish EOF from read errors with ferror() and bail out with -1 on a real failure. Also use size_t for the return value of fread(). Link: https://github.com/openwrt/libubox/pull/42 Co-Authored-By: Claude Opus 4.7 Signed-off-by: Hauke Mehrtens

ustream: avoid INT_MAX overflow on malloc in ustream_vprintf()

2026-05-03T20:18:01Z

vsnprintf() returns the length the formatted output would have had if the buffer were unlimited. When that length is INT_MAX, the following 'maxlen + 1' wraps to a negative value (-> huge size_t), so malloc() either fails or, on 32-bit systems, returns a far too small allocation that the subsequent vsnprintf() then overruns. Reject INT_MAX explicitly in both call sites that allocate the oversized buffer. Link: https://github.com/openwrt/libubox/pull/42 Co-Authored-By: Claude Opus 4.7 Signed-off-by: Hauke Mehrtens

blobmsg: fix integer overflow in blobmsg_realloc_string_buffer()

2026-05-03T20:17:58Z

'maxlen + 1' wraps to 0 when maxlen is UINT_MAX, and the mixed signed/unsigned subtraction that produced 'required' could store a huge unsigned value into a signed int. In either case the function might return without growing the buffer while the caller assumes maxlen bytes are now available, leading to an out-of-bounds write. Reject UINT_MAX explicitly (matching blobmsg_alloc_string_buffer()) and rewrite the size comparison so the arithmetic stays in unsigned space and is bounded. Link: https://github.com/openwrt/libubox/pull/42 Co-Authored-By: Claude Opus 4.7 Signed-off-by: Hauke Mehrtens

json_script: avoid alloca() on attacker-controlled pattern length

2026-05-03T20:17:55Z

eval_string() copied the pattern into a stack buffer sized via alloca(strlen(pattern) + 1). Patterns come from the JSON script input and may be arbitrarily large; a multi-MB pattern would smash the stack and crash (or, in the worst case, jump past a guard page). Allocate the working copy on the heap instead and free it before returning. While at it, drop the strcpy() in favour of memcpy() with the length we just computed. Link: https://github.com/openwrt/libubox/pull/42 Co-Authored-By: Claude Opus 4.7 Signed-off-by: Hauke Mehrtens

blob: use size_t for blob_memdup() length

2026-05-03T20:17:52Z

blob_pad_len() returns size_t and the value is used as a memory allocation/copy size. Storing it in a signed int could truncate or turn the value negative on platforms or inputs where the padded length exceeds INT_MAX, leading to a too-small malloc() and an out-of-bounds memcpy(). Link: https://github.com/openwrt/libubox/pull/42 Co-Authored-By: Claude Opus 4.7 Signed-off-by: Hauke Mehrtens

blob: fix integer overflow in buffer growth functions

2026-05-03T20:17:49Z

blob_buffer_grow() computed delta and the new buffer size as plain int additions without checking for overflow. With sufficiently large inputs the result could wrap around to a small positive value, so realloc() would shrink the buffer and subsequent writes would overflow the heap. blob_buf_grow() suffered from the same issue: '(buf->buflen + required) > BLOB_ATTR_LEN_MASK' is evaluated after the addition already wraps, so the bound check could be bypassed. Reject negative inputs explicitly and rewrite the bound checks so the arithmetic cannot overflow. Link: https://github.com/openwrt/libubox/pull/42 Co-Authored-By: Claude Opus 4.7 Signed-off-by: Hauke Mehrtens

utils: fix integer overflow in __calloc_a()

2026-05-03T20:17:46Z

The accumulated allocation size was stored in a signed int, so summing several large size_t arguments could overflow silently and result in a calloc() that is much smaller than intended. Subsequent writes through the per-chunk pointers would then corrupt the heap. Use size_t for the accumulator and explicitly check for overflow on both the per-argument alignment rounding and the running sum. Link: https://github.com/openwrt/libubox/pull/42 Co-Authored-By: Claude Opus 4.7 Signed-off-by: Hauke Mehrtens

jshn: fix integer overflow and type confusion in jshn_parse_file

2026-05-03T20:17:43Z

Two problems existed in jshn_parse_file(): 1. Integer overflow: sb.st_size is off_t (signed). The expression sb.st_size + 1 triggers signed integer overflow (undefined behaviour) when sb.st_size equals OFF_MAX. Add an explicit bounds check (sb.st_size < 0 || (size_t)sb.st_size >= SIZE_MAX) before the allocation and cast to size_t to make the arithmetic well-defined. 2. Type mismatch in read() comparison: read() returns ssize_t while sb.st_size is off_t. Comparing them directly is implementation- defined when the values differ in sign or width. Store the read() result in a ssize_t variable and compare against sb.st_size explicitly to catch both errors (n < 0) and short reads (n != size). Link: https://github.com/openwrt/libubox/pull/42 Co-Authored-By: Claude Sonnet 4.6 Signed-off-by: Hauke Mehrtens

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

blobmsg: use correct byte-order macro when setting BLOB_ATTR_EXTENDED

2026-05-03T20:17:35Z

blobmsg_new() sets the BLOB_ATTR_EXTENDED flag in attr->id_len, which is stored in big-endian format. The code used be32_to_cpu() to convert the constant before OR-ing it into the field, but the correct macro is cpu_to_be32() since we are converting from CPU byte order to the on-wire big-endian format. Both macros produce identical results (byte-swapping is its own inverse), so this is a correctness/readability fix with no behavioral change. Link: https://github.com/openwrt/libubox/pull/42 Co-Authored-By: Claude Opus 4.6 Signed-off-by: Hauke Mehrtens