https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280039
Bug ID: 280039
Summary: bluetooth socket security filter incomplete
initialization
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
During buildkernel with gcc13 on amd64, gcc issues this warning:
In file included from
/usr/src/freebsd/sys/netgraph/bluetooth/socket/ng_btsocket_hci_raw.c:36:
/usr/src/freebsd/sys/netgraph/bluetooth/socket/ng_btsocket_hci_raw.c: In
function 'ng_btsocket_hci_raw_init':
/usr/src/freebsd/sys/sys/systm.h:282:33: warning: 'memset' used with length
equal to number of elements without multiplication by element size
[-Wmemset-elt-size]
282 | #define memset(buf, c, len) __builtin_memset((buf), (c), (len))
| ^~~~~~~~~~~~~~~~
/usr/src/freebsd/sys/netgraph/bluetooth/socket/ng_btsocket_hci_raw.c:810:9:
note: in expansion of macro 'memset'
810 | memset(&ng_btsocket_hci_raw_sec_filter->events, 0xff,
| ^~~~~~
This appears to be a genuine bug in initialization of the bluetooth
socket events security filter.
https://cgit.freebsd.org/src/tree/sys/netgraph/bluetooth/socket/ng_btsocket_hci_raw.c?id=7f7b4926a779845116913c85ecbb10527daeab02#n801
/*
* XXX How paranoid can we get?
*
* Initialize security filter. If bit is set in the mask then
* unprivileged socket is allowed to send (receive) this command
* (event).
*/
/* Enable all events */
memset(&ng_btsocket_hci_raw_sec_filter->events, 0xff,
sizeof(ng_btsocket_hci_raw_sec_filter->events)/
sizeof(ng_btsocket_hci_raw_sec_filter->events[0]));
/* Disable some critical events */
f = ng_btsocket_hci_raw_sec_filter->events;
bit_clear(f, NG_HCI_EVENT_RETURN_LINK_KEYS - 1);
bit_clear(f, NG_HCI_EVENT_LINK_KEY_NOTIFICATION - 1);
bit_clear(f, NG_HCI_EVENT_VENDOR - 1);
The effect of the obvious fix to actually set all bits to 1 would be to
permit additional events on unprivileged sockets. It's unclear if this
is the desired policy. Someone knowledgeable should take a look.
Additionally perhaps this initialization ought to be reversed to use
default deny with explicit allows.
I posted a phabricator review that naively follows the apparent intent
of the code:
https://reviews.freebsd.org/D45707
--
You are receiving this mail because:
You are the assignee for the bug.
