OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Packages
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Chris Nisbet - 13.02.2020
Last edited by Petr Štetiar - 28.02.2020

FS#2833 - libubox: bug in blobmsg_check_array()

Description: I believe there is a problem in blobmsg_check_array(), where the incorrect length is being passed to the new ‘_len’ variant of the function.

I ran into this problem when shifting from an older version of libubox to the current tip of master. The code worked fine with the older library, but a call to

blobmsg_check_array(attr, BLOBMSG_TYPE_STRING);
failed with a piece of JSON that looked similar to this...

	"array_a" : [
			"array_b": [

where the array “array_b” was the one getting checked.

In the pre ‘_len’ code, blobmsg_check_array() used to iterate over the entries in the array using

blobmsg_for_each_attr(cur, attr, rem)
Note that blobmsg_for_each_attr() assigns the value obtained by blob_len() to ‘rem’

#define blob_for_each_attr(pos, attr, rem) \

for (rem = attr ? blob_len(attr) : 0, \
     pos = (struct blob_attr *) (attr ? blob_data(attr) : NULL); \
     rem >= sizeof(struct blob_attr) && (blob_pad_len(pos) <= rem) && \
     (blob_pad_len(pos) >= sizeof(struct blob_attr)); \
     rem -= blob_pad_len(pos), pos = blob_next(pos))

There have been a couple of recent changes to blobmsg_check_array() and I believe the most recent one (commit: 20a070f08139) still doesn’t have it quite right. I believe that blobmsg_check_array() should be using blob_len() so that it uses the same length used prior to the new ‘_len’ changes.
Please find attached a couple of patches for your consideration. I believe that one fixes the issue, and the other adds a tests to confirm that the issue is fixed.

Closed by  Petr ┼átetiar
28.02.2020 20:27
Reason for closing:  Fixed
Additional comments about closing:  

Kindly fixed by Jo via
https:/ / a6ac85655329d8b06 in master, https:/ / 5092aa96bf951565d in 19.07 and with https:/ / 05f11089962f33a4f in 18.06, thanks for the report and patches.

Shawn commented on 16.02.2020 06:40

Same issue here under 18.06 branch code on ramips/mt76x8 target, which cause the following ubus call failure.

# ubus call umdns set_config '{ "interfaces": [ "eth0" ] }'
Command failed: Invalid argument

which makes umdns broken

Karl Palsson commented on 21.02.2020 11:19

Tested-by: Karl Palsson Fixes umdns on 1907 branch

Jonathan commented on 23.02.2020 16:19

Confirm this is a problem in 19.07.0 on MT76, mDNS fails to respond to broadcast identification requests.


Available keyboard shortcuts


Task Details

Task Editing