Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#2833 - libubox: bug in blobmsg_check_array() #7652

Closed
openwrt-bot opened this issue Feb 13, 2020 · 3 comments
Closed

FS#2833 - libubox: bug in blobmsg_check_array() #7652

openwrt-bot opened this issue Feb 13, 2020 · 3 comments
Labels

Comments

@openwrt-bot
Copy link

ChrisNisbet01:

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.

@openwrt-bot
Copy link
Author

shawnchain:

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

@openwrt-bot
Copy link
Author

karlp:

Tested-by: Karl Palsson karlp@etactica.com
Fixes umdns on 1907 branch

@openwrt-bot
Copy link
Author

JonFo:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant