Two problems in hci_num_completed_packets().
Number_of_Handles is a single octet, but it was read with BT_LE162HOST(),
which takes the first octet of the handle that follows it as the high
byte. A one-octet field could therefore produce a loop count of up to
65535.
The loop was then bounded only by that count and not by the data that was
actually received, so it walked past the end of the event, reading handle
and count pairs out of whatever followed it.
Read the field at its declared width, and require the pairs the event
claims to have been received before reading them.
Per-connection credit accounting, which this handler still does not do,
is a separate change.
Ref: Core v6.0, Vol 4, Part E, 7.7.19 (Number Of Completed Packets event)
Testing: builds for sim:bluetooth with Make; every commit in this series
verified to build individually.
Signed-off-by: Alan C. Assis <acassis@gmail.com>
Assisted-by: Claude Code Opus 5
The GATT ioctls looked up a connection by address and then checked only
that a connection object existed, not that it had reached CONNECTED.
While a connection is still being established conn->att is NULL, and
bt_att_create_pdu() dereferenced it to read the ATT MTU, so issuing
SIOCBTEXCHANGE, SIOCBTDISCOVER, SIOCBTGATTRD or SIOCBTGATTWR for a peer
that is merely pending faulted. Any task with access to the network
device can reach that path, and in PROTECTED and KERNEL builds the fault
is taken in the kernel on behalf of user code.
Require CONNECTED in those four ioctls, releasing the reference the
lookup took, and make bt_att_create_pdu() return NULL when there is no
ATT context instead of relying on every caller having checked first.
Testing: builds for sim:bluetooth with Make; every commit in this series
verified to build individually. On sim:bluetooth with CONFIG_BTSAK=y:
nsh> ifup bnep0
ifup bnep0...OK
nsh> bt bnep0 gatt connect 11:22:33:44:55:66 public
Connect pending...
nsh> bt bnep0 gatt exchange-mtu 11:22:33:44:55:66 public
ERROR: ioctl(SIOCBTEXCHANGE) failed: 107
107 is ENOTCONN, and the shell continues to run; before this change the
same sequence terminated the simulator in bt_att_create_pdu().
Signed-off-by: Alan C. Assis <acassis@gmail.com>
Assisted-by: Claude Code Opus 5
hci_event() consumed the event header and dispatched on the event code
without checking that a header had been received, and hci_le_meta_event()
did the same for the subevent code. Each handler then cast the remaining
buffer to its event structure and read fields out of it, so a short event
was parsed from whatever followed it in memory - including the fields
that identify a connection and carry its encryption state.
Check that the header is present before reading it, that the parameters
the event declares were actually received, and that enough parameters
remain for the structure the selected handler casts to. Events failing a
check are dropped with a diagnostic rather than parsed.
le_adv_report() continues to do its own checking, because the report
count and the per-report lengths vary within that event.
Ref: Core v6.0, Vol 4, Part E, 5.4.4 (HCI Event packets)
Ref: Core v6.0, Vol 4, Part E, 7.7 (Events)
Testing: builds for sim:bluetooth with Make; every commit in this series
verified to build individually. Not yet exercised at runtime - the
scriptable controller injects truncated events separately.
Signed-off-by: Alan C. Assis <acassis@gmail.com>
Assisted-by: Claude Code Opus 5
bt_conn_receive() read the 4-octet L2CAP header out of the first fragment
of a PDU without checking that 4 octets had been received, and then
computed the outstanding length by subtracting the fragment length from
the declared PDU length.
Two problems follow. A fragment shorter than the header was parsed from
whatever happened to follow it in the buffer. And a fragment carrying
more data than the PDU it declares made the subtraction wrap, because
conn->rx_len is 16 bits: the connection was then left expecting up to
65535 further octets, holding the partial PDU and accumulating later
fragments against an expectation that could never be satisfied.
Check that the fragment is long enough to hold a header before reading
it, and that it does not exceed the PDU it declares before computing what
remains. Drop the fragment and reset the reassembly state otherwise.
Ref: Core v6.0, Vol 3, Part A, 3.1 (B-frame format)
Ref: Core v6.0, Vol 4, Part E, 5.4.2 (HCI ACL Data packets)
Testing: builds for sim:bluetooth with Make; every commit in this series
verified to build individually. Not yet exercised at runtime - the
scriptable controller adds the truncated and oversized fragment cases
separately.
Signed-off-by: Alan C. Assis <acassis@gmail.com>
Assisted-by: Claude Code Opus 5
le_adv_report() took the report count and each report's data length from
the event and used them without checking either against the data that was
actually received:
- the declared data length indexes the RSSI octet, so a length larger
than the event reads past the end of the buffer;
- the loop was bounded only by the report count, so a count larger than
the payload walks off the end of it;
- bt_buf_consume() only checks its bound with DEBUGASSERT(), so on a
build without assertions the buffer length underflows rather than
reporting the problem.
Check that the event is long enough for the count, then check each report
against the remaining length before reading its data or its RSSI, and
stop parsing when a report does not fit.
While here, include the RSSI octet when advancing to the next report.
sizeof() of the report structure does not account for it, because the
data member is a zero-length array, so every report after the first
started one octet early.
Ref: Core v6.0, Vol 4, Part E, 7.7.65.2 (LE Advertising Report event)
Testing: builds for sim:bluetooth with Make; every commit in this series
verified to build individually. Not yet exercised at runtime - the
scriptable controller that can inject a malformed report is added
separately.
Signed-off-by: Alan C. Assis <acassis@gmail.com>
Assisted-by: Claude Code Opus 5
att_find_info_rsp() computed the per-record stride with sizeof(info.i16)
and sizeof(info.i128), but "info" is a union of two pointers, so both
expressions evaluate to the pointer width instead of the size of the
record that the response format selects. The records are 4 octets for a
16-bit UUID and 18 octets for a 128-bit UUID, so the 128-bit path
advanced by 4 (or 8) octets per iteration while reading an 18-octet
record: handles and UUIDs were parsed from the wrong offsets and the walk
ran past the end of the received PDU. On 64-bit builds the 16-bit path
was wrong too.
Take the stride from the record structures, and require the response to
carry whole records before walking it, since the loop advances one record
at a time and a partial trailing record would be parsed as a whole one.
Ref: Core v6.0, Vol 3, Part F, 3.4.3.2 (ATT_FIND_INFORMATION_RSP)
Testing: sim:bluetooth builds with Make, no new warnings. Not yet
exercised at runtime; the scriptable controller that can inject a
malformed Find Information Response is added separately.
Signed-off-by: Alan C. Assis <acassis@gmail.com>
Assisted-by: Claude Code Opus 5
bt_conn_send() splits an outgoing L2CAP PDU into HCI ACL fragments no
larger than g_btdev.le_mtu, the controller's HCI ACL data packet length.
The first fragment caps its length correctly:
len = remaining;
if (len > g_btdev.le_mtu)
{
len = g_btdev.le_mtu;
}
The continuation loop below uses '<' instead of '>', so a continuation
shorter than le_mtu has its length raised to le_mtu rather than left
alone. Both len and remaining are uint16_t, which turns a wrong length
into an underflow:
With le_mtu 251 and a 300-byte PDU, the first fragment takes 251 bytes
and leaves remaining == 49. The loop then raises len from 49 to 251, so
memcpy(bt_buf_extend(buf, len), ptr, len);
reads 202 bytes past the end of the source, and
remaining -= len;
evaluates 49 - 251 as a uint16_t, wrapping to 65334. On the next
iteration len is 65334, which is not less than le_mtu, so it survives
the cap. bt_buf_extend() carries only a DEBUGASSERT on tailroom, so
with assertions disabled it adds 65334 to buf->len and returns, and the
memcpy writes 64 KB into a pooled buffer sized for a few hundred bytes.
Only the last fragment of a multi-fragment PDU is normally shorter than
le_mtu, so the first fragmented transmission triggers it.
Signed-off-by: AlmAck <gluca86@gmail.com>
Rename atomic_fetch_add/sub/or/and/xor to atomic_add/sub/or/and/xor
to avoid conflicts with the C/C++ standard library naming. The
atomic_fetch_xxx naming is reserved by the standard; keeping it causes
function name conflicts when source files indirectly include both
<nuttx/atomic.h> and <atomic>/<stdatomic.h>.
Signed-off-by: zhangyu117 <zhangyu117@xiaomi.com>
hci_acl() looked up the connection with bt_conn_lookup_handle(), which
returns a new reference, but never released it. This leaked one conn
reference for every received ACL packet.
bt_conn_receive() also consumes the buffer on every path: it forwards
to l2cap (which releases) or stores the buffer in conn->rx without an
addref. The hci_rx_work() worker then called bt_buf_release() on the
same buffer, which caused a double free or use-after-free.
Take an extra buffer reference for the worker to release, and release
the connection reference from the lookup.
Assisted-by: Fable
Signed-off-by: AbhinavMir <atg271@gmail.com>
debug.h is a NuttX-specific, non-POSIX header. Placing it in the
top-level include/ directory creates naming conflicts with external
projects that define their own debug.h.
This commit moves the canonical header to include/nuttx/debug.h,
following the NuttX convention for non-POSIX/non-standard headers,
and updates all in-tree references.
A backward-compatibility shim is left at include/debug.h that
emits a deprecation #warning and re-includes <nuttx/debug.h>,
allowing out-of-tree code to continue building while migrating.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Fix 269 occurrences of duplicate "the" word typo found in 209 files
across source code, header files, and configuration.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
Nuttx currently has 2 types of sleep interfaces:
1. Signal-scheduled sleep: nxsig_sleep() / nxsig_usleep() / nxsig_nanosleep()
Weaknesses:
a. Signal-dependent: The signal-scheduled sleep method is bound to the signal framework, while some driver sleep operations do not depend on signals.
b. Timespec conversion: Signal-scheduled sleep involves timespec conversion, which has a significant impact on performance.
2. Busy sleep: up_mdelay() / up_udelay()
Weaknesses:
a. Does not actively trigger scheduling, occupy the CPU loading.
3. New interfaces: Scheduled sleep: nxsched_sleep() / nxsched_usleep() / nxsched_msleep() / nxsched_ticksleep()
Strengths:
a. Does not depend on the signal framework.
b. Tick-based, without additional computational overhead.
Currently, the Nuttx driver framework extensively uses nxsig_* interfaces. However, the driver does not need to rely on signals or timespec conversion.
Therefore, a new set of APIs is added to reduce dependencies on other modules.
(This PR also aims to make signals optional, further reducing the code size of Nuttx.)
Signed-off-by: chao an <anchao.archer@bytedance.com>
Modify the kernel to use only atomic_xx and atomic64_xx interfaces,
avoiding the use of sizeof or typeof to determine the type of
atomic operations, thereby simplifying the kernel's atomic
interface operations.
Signed-off-by: zhangyuan29 <zhangyuan29@xiaomi.com>
change bt_driver_register/unregister function name to
bt_driver_set/unset, which would be prepared for bt_driver.h
Signed-off-by: chengkai <chengkai@xiaomi.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
By enabling the config `CONFIG_BLUETOOTH_TXCMD_PINNED_TO_CORE` and
setting the value of `CONFIG_BLUETOOTH_TXCMD_CORE`, it's possible
to pin the HCI TX thread to a specific core on a SMP-enabled setup.
This is necessary for devices that require that the function that
sends data (`bt_send`) to be called from a specific core.
1. Update all CMakeLists.txt to adapt to new layout
2. Fix cmake build break
3. Update all new file license
4. Fully compatible with current compilation environment(use configure.sh or cmake as you choose)
------------------
How to test
From within nuttx/. Configure:
cmake -B build -DBOARD_CONFIG=sim/nsh -GNinja
cmake -B build -DBOARD_CONFIG=sim:nsh -GNinja
cmake -B build -DBOARD_CONFIG=sabre-6quad/smp -GNinja
cmake -B build -DBOARD_CONFIG=lm3s6965-ek/qemu-flat -GNinja
(or full path in custom board) :
cmake -B build -DBOARD_CONFIG=$PWD/boards/sim/sim/sim/configs/nsh -GNinja
This uses ninja generator (install with sudo apt install ninja-build). To build:
$ cmake --build build
menuconfig:
$ cmake --build build -t menuconfig
--------------------------
2. cmake/build: reformat the cmake style by cmake-format
https://github.com/cheshirekow/cmake_format
$ pip install cmakelang
$ for i in `find -name CMakeLists.txt`;do cmake-format $i -o $i;done
$ for i in `find -name *\.cmake`;do cmake-format $i -o $i;done
Co-authored-by: Matias N <matias@protobits.dev>
Signed-off-by: chao an <anchao@xiaomi.com>
This bluetooth stack remains in an inconsistent state when
the bluetooth HCI module is removed. This change adds a
bt_netdev_unregister function that can be used to clean up
after a module is removed. Some global variables are also
set to their default values.
In the past, header file paths were generated by the incdir command
Now they are generated by concatenating environment variables
In this way, when executing makefile, no shell command will be executed,
it will improve the speed of executing makfile
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
