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>
This change fixes NuttX’s CMake support when NuttX is embedded
in another project via add_subdirectory(). CMake’s CMAKE_SOURCE_DIR
and CMAKE_BINARY_DIR refer to the outermost project, causing NuttX
to access its .config, generated files, host tools, and build artifacts
in the parent project’s directories. The fix introduces NUTTX_DIR and
NUTTX_BINARY_DIR, based on CMAKE_CURRENT_SOURCE_DIR and
CMAKE_CURRENT_BINARY_DIR, and consistently uses them for NuttX
self-references while preserving existing standalone builds. It fixes
the Kconfig initialization failure reported in #19697 and allows an
embedded sim:nsh build to configure, build, and boot successfully.
The change affects only the CMake build system (not Make or Kconfig
defaults), requires the corresponding nuttx-apps change, and does not
extend add_subdirectory() support to cross-compiled non-sim boards due
to CMake’s toolchain-file limitation.
Fixes#19697.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Alan Carvalho de Assis <acassis@gmail.com>
During the Toybox port to NuttX, Claude noticed that changes in the
menuconfig weren't taking affect. This issue exists for a long time on
NuttX, in fact BayLibre's presentation from 2017 make jokes about our
building system not been reliable:
https://www.youtube.com/watch?v=XUJK2htXxKw&t=320s
Stale archive members from $(AR)'s additive-only behavior can linger
after Kconfig toggles change which files provide a symbol, causing dead
weight or "multiple definition" link errors on incremental builds.
Fixed by splitting ARCHIVE into two macros: ARCHIVE keeps the original
additive behavior for apps/libapps.a, which many independent
subdirectories contribute to across a build, while the new
ARCHIVE_REBUILD deletes then archives for the far more common case
of a single Makefile building its own self-contained $(OBJS)
- all 39 such call sites now use it.
Assisted-By: Claude Sonnet 5
Signed-off-by: Alan C. Assis <acassis@gmail.com>
Permissions (Part 2)
Description:
In kernel builds, any unprivileged process running on the NuttX
device can open /dev/efuse and attempt to read/write fuse content.
Reading the fuses may provide valuable information to an attacker
controlling the user process. The write operation, in extreme cases
where the fuse blocks are not locked, may brick the device.
DISCLAIMER: I tried to be strict with the settings, better to relax them
later if it's needed.
This is part of https://github.com/apache/nuttx/issues/19410
See https://github.com/apache/nuttx/issues/19410
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.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>
When all signals are disabled, nxsig_notification is not available and
should not be invoked. Remove the call to avoid build and runtime issues
in no-signal configurations.
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
Intermediate files of make depend like .ddc and .dds may remain
when make is interrupted. Remove them using make distclean.
Signed-off-by: SPRESENSE <41312067+SPRESENSE@users.noreply.github.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>
This patch fixed userspace headers conflict. Architecture-related definition and API should not be exposed to users.
Signed-off-by: ouyangxiangzhen <ouyangxiangzhen@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>
Revert "Parallelize depend file generation"
This reverts commit d5b6ec450f.
parallel depend ddc does not significantly speed up compilation,
intermediately generated .ddc files can cause problems if compilation is interrupted unexpectedly
Signed-off-by: xuxin19 <xuxin19@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>
The `xxx_ipv6multicast` function in each driver is not adapted to
multiple IPv6 addresses yet, and they're redundant, so try to take them
into common code.
Change:
1. Add MAC `g_ipv6_ethallnodes` and `g_ipv6_ethallrouters` in
`icmpv6_devinit` and call them in `netdev_register`
2. Add multicast MAC for Neighbor Solicitation when adding any IPv6
address, and remove them when IPv6 address is removed
3. Select `NET_MCASTGROUP` when `NET_ICMPv6` because now we need
`d_addmac` when we have ICMPv6
Note:
We want modules outside net stack to call functions like
`netdev_ipv6_add` and never touch the related MAC address, so these MAC
functions are added as internal functions to `net/netdev/netdev.h`
Signed-off-by: Zhe Weng <wengzhe@xiaomi.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.
