blob_parse expects blobs from trusted inputs, but it can be supplied
with possibly malicious blobs from untrusted inputs as well, which might
lead to undefined behaviour and/or crash of ubus daemon. In order to
prevent such conditions, switch to blob_parse_untrusted which should
hopefully handle such untrusted inputs appropriately.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
scan-build from clang-9 has reported following:
libubox/list.h:141:2: warning: Use of memory after it is freed
_list_add(_new, head, head->next);
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This dereference could possibly happen if the calloc call fails as the
return value is unchecked. While at it refactor the code little bit to
make it easier to follow, use safe list iterator and provide return
value for ubusd_monitor_connect.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
scan-build from clang-9 has reported following:
libubox/list.h:83:22: warning: Use of memory after it is freed
entry->next->prev = entry->prev;
^~~~~~~~~~~
ubusd_event.c:42:3: warning: Use of memory after it is freed
ubusd_delete_event_source(ev);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Which might be a false positives, but in order to make the code pass the
static analyzer checks, rewrite the while loops on lists with the safe
list iterator.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
scan-build from clang-9 has reported following:
ubus.c:837:16: warning: Access to field 'rnotify' results in a dereference of a null pointer (loaded from variable 'sub')
sub->rnotify = luaL_ref(L, -2);
Which is false positive as the lua_error() does a long jump and
therefore never returns and this long jump probably confuses the static
analyzer. So this patch workarounds this false positive by helping
static analyzer by using common Lua idiom which is to return
lua_error()'s return value.
Ref: https://www.lua.org/manual/5.1/manual.html#lua_error
Addresses-Coverity-ID: 1412355 ("Dereference after null check")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Fixes following error reported by clang-9 analyzer:
examples/server.c:244:2: warning: Value stored to 'argc' is never read
argc -= optind;
^ ~~~~~~
examples/server.c:245:2: warning: Value stored to 'argv' is never read
argv += optind;
^ ~~~~~~
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Uses currently proof-of-concept openwrt-ci[1] in order to:
* improve the quality of the codebase in various areas
* decrease code review time and help merging contributions faster
* get automagic feedback loop on various platforms and tools
- out of tree build with OpenWrt SDK on following targets:
* ath79-generic
* imx6-generic
* malta-be
* mvebu-cortexa53
- out of tree native build on x86/64 with GCC (versions 7, 8, 9) and Clang 10
- out of tree native x86/64 static code analysis with cppcheck and
scan-build from Clang 9
1. https://gitlab.com/ynezz/openwrt-ci/
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Fixes following error reported by clang-9 analyzer:
libubus.c:286:19: error: incompatible pointer types assigning to 'struct blob_attr *' from 'char *' [-Werror,-Wincompatible-pointer-types]
ctx->msgbuf.data = (char *) calloc(UBUS_MSG_CHUNK_SIZE, sizeof(char));
Result of 'calloc' is converted to a pointer of type 'struct blob_attr',
which is incompatible with sizeof operand type 'char'.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
clang-9 on x86/64 has reported following warnings/errors:
libubus-acl.c:123:2: error: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
libubus-io.c:108:18: error: comparison of integers of different signs: 'int' and 'size_t' (aka 'unsigned long') [-Werror,-Wsign-compare]
libubus-io.c:395:56: error: comparison of integers of different signs: 'ssize_t' (aka 'long') and 'size_t' (aka 'unsigned long') [-Werror,-Wsign-compare]
libubus-req.c:441:4: error: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
ubusd_acl.c:119:18: error: comparison of integers of different signs: 'int' and 'unsigned long' [-Werror,-Wsign-compare]
ubusd_acl.c:152:5: error: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
ubusd_acl.c:348:3: error: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
ubusd_acl.c:352:3: error: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
ubusd_acl.c:357:3: error: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
ubusd_acl.c:362:3: error: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
ubusd_acl.c:367:3: error: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
ubusd_acl.c:447:16: error: comparison of integers of different signs: 'int' and '__size_t' (aka 'unsigned long') [-Werror,-Wsign-compare]
ubusd_acl.c:502:18: error: comparison of integers of different signs: 'int' and 'unsigned long' [-Werror,-Wsign-compare]
ubusd.c:123:13: error: comparison of integers of different signs: 'int' and 'unsigned long' [-Werror,-Wsign-compare]
ubusd.c:170:15: error: comparison of integers of different signs: 'int' and 'unsigned long' [-Werror,-Wsign-compare]
ubusd.c:262:43: error: comparison of integers of different signs: 'int' and 'unsigned long' [-Werror,-Wsign-compare]
ubusd.c:287:30: error: comparison of integers of different signs: 'int' and 'unsigned long' [-Werror,-Wsign-compare]
ubusd_event.c:170:18: error: comparison of integers of different signs: 'int' and 'unsigned long' [-Werror,-Wsign-compare]
ubusd_obj.c:71:2: error: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Fixes following clang-9 compiler warnings:
ubusd.c:99:18: error: field 'h' with variable sized type 'struct cmsghdr' not at the end of a struct or class is a GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end]
struct cmsghdr h;
^
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Fixes following clang-9 compiler warning:
ubusd.c:36:19: error: comparison of integers of different signs: 'uint32_t' (aka 'unsigned int') and 'int' [-Werror,-Wsign-compare]
if (ub->refcount == ~0) {
~~~~~~~~~~~~ ^ ~~
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Let's enforce additional automatic checks enforced by the compiler in
order to catch possible errors during compilation.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
If the header is read but not the remainder of the message, the stream
will be out of sync and parsing of future messages won't work
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Adds event send access list support in ubus via the "send" keyword
Example of a json file:
{
"user": "superuser",
"send": [ "wireless.*" ],
}
Signed-off-by: Koen Dergent <koen.cj.dergent@gmail.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Adds event listen access list support in ubus via the "listen" keyword
Example of a json file:
{
"user": "superuser",
"listen": [ "network.*" ],
}
Signed-off-by: Koen Dergent <koen.cj.dergent@gmail.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Wildcard access list support was failing in case multiple wildcards
entries were defined and/or when a specific access list string
overlapped a wildcard entry.
Root cause of the problem was the way how wildcard entries were sorted
in the avl tree by the compare function ubusd_acl_match_path resulting
into a non acces list match for a given object path.
The avl_tree sorting has been changed to make use of avl_strcmp; as such
there's no distinction anymore between non-wildcard and wildcard entries
in the avl_tree compare function as the boolean partial marks an access
list entry as a wildcard entry.
When trying to find an access list match for an object path the access list
tree is iterated as long as the number of characters between the access list
string and object path is monotonically increasing.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
UBUS_MSG_INVOKE and UBUS_MSG_DATA can be sent without UBUS_ATTR_DATA
present. Most ubus users assume that the msg argument passed can never
be NULL, so this change prevents a crash
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The callback function registered to be invoked when subscribing to a
notification was only passed the notification data (if any) but not the name
of the notification.
This name is now passed as second argument to remain backwards compatible.
The example subscriber.lua has also be updated.
Signed-off-by: Dirk Feytons <dirk.feytons@gmail.com>
==18834== Warning: invalid file descriptor -1 in syscall close()
==18834== at 0x5326D20: __close_nocancel (syscall-template.S:84)
==18834== by 0x5046DC7: ubus_process_obj_msg (libubus-obj.c:143)
==18834== by 0x5045E98: ubus_process_msg (libubus.c:106)
==18834== by 0x50468D0: ubus_handle_data (libubus-io.c:314)
==18834== by 0x4E3D125: uloop_run_events (uloop.c:198)
==18834== by 0x4E3D125: uloop_run_timeout (uloop.c:555)
==18834== by 0x109BEF: uloop_run (uloop.h:111)
==18834== by 0x109BEF: main (main.c:25)
Signed-off-by: John Crispin <john@phrozen.org>
valgrind complained about this one
==18632== Warning: invalid file descriptor -1 in syscall close()
==18632== at 0x5326D20: __close_nocancel (syscall-template.S:84)
==18632== by 0x5046C02: ubus_process_invoke (libubus-obj.c:98)
==18632== by 0x5046DC3: ubus_process_obj_msg (libubus-obj.c:142)
==18632== by 0x5045E98: ubus_process_msg (libubus.c:106)
==18632== by 0x50468D0: ubus_handle_data (libubus-io.c:314)
==18632== by 0x4E3D125: uloop_run_events (uloop.c:198)
==18632== by 0x4E3D125: uloop_run_timeout (uloop.c:555)
==18632== by 0x109BEF: uloop_run (uloop.h:111)
==18632== by 0x109BEF: main (main.c:25)
Signed-off-by: John Crispin <john@phrozen.org>
Even with the tx_queue-ing issue resolved, what
seems to happen afterwards, is that all the messages
seems to get through, but the client still loops
in the `ubus_complete_request()` waiting for
`req->status_msg` or for a timeout.
Though, the timeout does not seem to happen, because
the data is processed in `ubus_poll_data()`, with
a infinite poll() timeout (ubus_complete_request() is
called with timeout 0).
It's likely that either the `seq` or `peer` sent from
ubusd are wrong, and the client cannot get the correct
ubus request in `ubus_process_req_msg()`.
I haven't digged too deep into this ; setting the
`retmsg` object on the client struct seems to have
resolved any hanging with the `ubus list` command.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [fix placement of retmsg in cl]
Should save a few cycles, since the data that's
being changed is only the seq number.
And the `ub` is always created as shared.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This makes it clear that `ubus_msg_send()` is only
about sending and queue-ing messages, and has nothing
to do with free-ing.
It can be a bit misleading/confusing when trying to go
through the code and make assumptions about whether a
buffer is free'd in ubus_send_msg(), or is free'd outside.
In `ubusd_proto_receive_message()` the `ubus_msg_free()`
is now called before the `if (ret == -1)` check.
That way, all callbacks will have their messages free'd,
which is what's desired, but confusing, because:
* ubusd_handle_invoke() called ubus_msg_free() before returning -1
* ubusd_handle_notify() called ubus_msg_free() before returning -1
* ubusd_handle_response() called ubus_msg_send(,,free=true) before returning -1
* ubus_msg_send() would call ubus_msg_send(,,free=false)
* all other callback callers would `ubus_msg_send(,,free=true)`
(free the buffers in ubus_msg_send() )
In all other places, where `ubus_msg_send(,,free=true)`
an explicit `ubus_msg_free()` was added.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Objects are stored in the ubus context in an AVL tree. An AVL tree
node contains a pointer to a key value. For the ubus context, this
points to the id member of the object structure. In
ubus_remove_object_cb, the id member is set to zero and then after,
avl_delete is called and fails. To fix this, we call avl_delete
before setting the object id to zero.
Signed-off-by: Bob Ham <bob.ham@tomltd.co.uk>
Variable listen_timeout is redefined as a function resulting into
a compile issue. Define the function as ubus_cli_listen_timeout
to fix the compile issue.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
When ubus connect fails ctx->sock.eof will be set but ctx->sock.error
can be set as well. Reset ctx->sock.error as well when doing ubus
reconnect
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
For a shared ubus_msg_buf, the ubus_msg_ref function will
create a copy for queue-ing.
Problem is, that during the dequeue (especially) in client_cb,
the header is 0-ed (because it's was a newly alloc-ed buffer).
And during ubus_msg_writev(), the header info will be ignored
by the client.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
uloop_cancelled was used for two purposes within ubus_complete_request:
- interrupting recursive requests on SIGINT/SIGTERM
- breaking out of the poll loop in a recursive request that completed
Saving/restorung uloop_cancelled was buggy, leading to SIGTERM not being
processed properly. Simplify the logic by using a separate field for
internal use
Signed-off-by: Felix Fietkau <nbd@nbd.name>
An -1 returned by ubus_msg_writev() will be interpreted as
UINT_MAX during a check to see how much data had could be
written on the socket.
Because sizeof() will return size_t it will promote the
comparsion to unsigned
Signed-off-by: Mihai Richard <mihairichard@live.com>
If a synchronous operation is executed on a ubus context after
uloop_done() has been called, the context's pending_timer
may remain in uloop's list of timeouts.
This leads to undefined behaviour during next execution of uloop
code, as it may be referring to unavailable memory or memory
that has been allocated for different purposes.
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Signed-off-by: Abhimanyu Vishwakarma <Abhimanyu.Vishwakarma@imgtec.com>
