OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • 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": [
				"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.

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

Kindly fixed by Jo via
https:/ /git.openwrt.org/955634b473284847e3c8281 a6ac85655329d8b06 in master, https:/ /git.openwrt.org/65030d81f3dfda1c250b77e 5092aa96bf951565d in 19.07 and with https:/ /git.openwrt.org/82fbd857471292ca71dc06b 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 karlp@etactica.com 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.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing