OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
    0%
  • 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

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": [
				"1"
			]
		}
	]
}

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.

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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing