Hi, please remember that the patches for CVE should not be disclosed until they are part of a release This is a public mailing list !
Bets regards Alin On Thu, Oct 29, 2026 at 1:13 PM chao an <[email protected]> wrote: > Alan, > > First, I need to clarify an important point: Xiaomi's zblue approach is > completely different from what I submitted in PR #20686 > https://github.com/apache/nuttx/pull/20686. Xiaomi's version keeps > Zephyr's > original headers and coding style largely intact, whereas my libs/zblue > submission is fully adapted for NuttX — headers restructured to > include/nuttx/net/bluetooth/, OS adaptation layer integrated, and the > entire tree reorganized to fit NuttX's build system. They are not the same > technical approach. > > I've already laid out the advantages of having the protocol stack in-tree > in PR #20686 — build integration, API cohesion, OS-level optimization > opportunities, and avoiding the friction of out-of-tree maintenance. > Reading your latest reply, I have to be honest: I'm disappointed, because > it feels like you haven't really engaged with what I was saying there. > > Regarding security — you keep raising this concern, and I want to address > it directly. Security issues are solvable. I don't just say this in the > abstract — I'm currently fixing 9 security vulnerabilities across NuttX's > networking and USB subsystems: > > 1. IPv6 extension-header out-of-bounds read — #20885 > https://github.com/apache/nuttx/pull/20885 > 2. MLDv2 report record-count out-of-bounds read — #20886 > https://github.com/apache/nuttx/pull/20886 > 3. ICMPv6 Router Advertisement prefix option out-of-bounds read — #20888 > https://github.com/apache/nuttx/pull/20888 > 4. USB host config-descriptor walk out-of-bounds read and infinite loop > — #21101 https://github.com/apache/nuttx/pull/21101 > 5. USB host composite copyinterface heap buffer overflow — #21101 > https://github.com/apache/nuttx/pull/21101 > 6. USB host composite member array out-of-bounds write — #21101 > https://github.com/apache/nuttx/pull/21101 > 7. CDC-MBIM NCM frame NDP/DPE walk out-of-bounds read and infinite loop > — #20884 https://github.com/apache/nuttx/pull/20884 > 8. USB mass-storage zero block size divide-by-zero in partition scan — > #21101 https://github.com/apache/nuttx/pull/21101 > 9. CDC-MBIM transmit divide-by-zero on zero bulk max packet size — > #20884 https://github.com/apache/nuttx/pull/20884 > > These are all in NuttX's own native code — networking, USB host, CDC — > subsystems I've worked on extensively. A CVE in any of these would likewise > disrupt devices in the field. Security is a universal concern for every > line of code we ship, regardless of its origin. We deal with it through > review, testing, and prompt fixes — exactly what I'm doing here. I > genuinely don't understand why you keep bringing this up as if it were > unique to zblue. > > > BRs, > > Alan C. Assis <[email protected]> 于2026年10月29日周四 19:38写道： > > > Hi Anchao and Chengkai, > > > > Thank you for moving this discussion forward. > > > > I think the agreement that NuttX should have only one Bluetooth stack > (the > > Zephyr ZBlue stack) is not universally agreed upon, as we saw in the PR > > discussions. > > > > If NuttX selects only one BLE stack it should be its own stack (which is > > very limited currently and not a feasible option at this moment). > > > > Moving zblue to nuttx-apps and making it just an option like the NimBLE > > appears to be the right thing to do. > > > > It could be the stack that most people will use (instead of NimBLE or the > > native one), but it shouldn't be the only option because it shares almost > > 1M LoC from Zephyr and poses a huge security risk due to the monoculture > > effect: a CVE found on Zephyr ZBlue would disrupt all their devices on > the > > field and also all NuttX devices using zblue. > > > > Imagine if Windows were open-source and someone in the Linux community > > decided to use the Windows windowing subsystem. It would make it very > easy > > for vendors to implement graphical applications for both Windows and > Linux, > > but any vulnerability found in Windows would affect Linux. That is > > basically the scenario here for NuttX. > > > > As I said I like the idea of having the option to use a Bluetooth stack > > like zblue until we evolve our own stack. > > > > BR, > > > > Alan > > > > On Thu, Oct 29, 2026 at 3:51 AM chao an <[email protected]> wrote: > > > > > Hi Chengkai, > > > > > > > > > > > > Thanks for the clarification. > > > > > > > > > > > > For question 1, by "NuttX-native integration" I mean more than only > > > Kconfig, > > > build glue, driver binding, and public headers. I think the > > Zephyr-derived > > > > > > Bluetooth host should be adapted into a NuttX-maintained stack, with a > > > > > > structure that can evolve toward the NuttX kernel/socket architecture. > > > > > > > > > > > > If we only keep the Zephyr Bluetooth source almost untouched and add a > > > large > > > compatibility layer around it, then I do not think that is the right > > > long-term > > > direction for the official NuttX Bluetooth architecture. > > > > > > > > > > > > For question 2, I think NimBLE and Zephyr Bluetooth are different > cases. > > > > > > NimBLE officially provides an OS abstraction layer, so each OS can > > > integrate it > > > through its own OSAL. Zephyr Bluetooth does not provide the same OSAL > > > boundary; > > > it is deeply tied to the Zephyr kernel model. > > > > > > > > > > > > That means zblue needs many Zephyr kernel API/header compatibility > > pieces: > > > > > > kernel objects, work queues, timers, buffers, iterable sections, and > > other > > > > > > Zephyr-style assumptions. Even if placed in nuttx-apps, it is not > really > > a > > > > > > clean standalone userspace library like NimBLE. > > > > > > > > > > > > My main concern is the long-term roadmap. If we preserve an almost > > > unmodified > > > Zephyr Bluetooth tree, then moving L2CAP and lower layers into the > NuttX > > > > > > kernel later will be very difficult, because L2CAP is tightly coupled > > with > > > > > > connection management, buffers, work queues, ATT/SMP, and the Zephyr > > > execution > > > model. That migration may become close to a second rewrite. > > > > > > > > > > > > This is different from the current libs/zblue PR, where the stack is > > > already > > > treated as NuttX-maintained code and can diverge from Zephyr where the > > > NuttX > > > architecture requires it. > > > > > > > > > > > > So my concern is not only external repo vs in-tree. The bigger concern > is > > > > > > whether we are building a real NuttX Bluetooth architecture, or mainly > > > keeping > > > a Zephyr runtime compatibility layer around the Zephyr Bluetooth stack. > > > > > > > > > > > > I agree this should be decided by the community, but my preference is > > still > > > to > > > adapt the code into a NuttX-native stack first, then submit it directly > > to > > > > > > nuttx.git or nuttx-apps.git depending on the agreed layering. > > > > > > BRs, > > > > > > 成凯 via dev <[email protected]> 于2026年10月29日周四 14:38写道： > > > > > > > hi anchao > > > > > > > > Thanks, good to see we are aligned on the direction. > > > > > > > > On open point 2, I think the difference is mainly about the starting > > > point, > > > > not the end state. We agree the stack should end up reviewed, built > and > > > > tested as part of the NuttX repositories. Step 3 of the plan already > > > allows > > > > moving the userspace part into nuttx-apps.git. > > > > > > > > Two things I would like to understand better: > > > > > > > > 1. By "NuttX-style public headers" and "native integration", do you > > mean > > > > reformatting the Zephyr-derived code to nxstyle, or only the NuttX > > > glue > > > > (Kconfig, build, driver binding, public API headers)? We are fine > > with > > > > the > > > > latter. The former makes picking up upstream fixes much harder, > > which > > > is > > > > our main concern. > > > > 2. NimBLE is already integrated this way (download at a pinned > > revision). > > > > Could you share which specific dependency or maintenance issues > you > > > are > > > > worried about? That would help us address them in the design. > > > > > > > > Since this is a project-level decision, I would like to hear from the > > PMC > > > > and everyone who has reviewed PR #20686 -- Xiang Xiao, Alan Carvalho > de > > > > Assis, Alin Jerpelea, raiden00pl, Tomasz CEDRO (cederom), LingaoM and > > > > casaroli -- on whether to start with a pinned external repository or > > with > > > > in-tree code. We will follow the community's decision. > > > > > > > > Best regards, > > > > Kai Cheng > > > > > > > > > > > > ________________________________ > > > > From: archer <[email protected]> > > > > Sent: Thursday, October 29, 2026 12:19 PM > > > > To: apache/nuttx > > > > Cc: 成凯; Mention > > > > Subject: [External Mail]Re: [apache/nuttx] net/bt: Add native > Bluetooth > > > > host stack (PR #20686) > > > > > > > > > > > > [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈 > > > > > > > > [https://avatars.githubusercontent.com/u/758493?s=20&v=4]anchao > left a > > > > comment (apache/nuttx#20686)< > > > > https://github.com/apache/nuttx/pull/20686#issuecomment-6487811997> > > > > > > > > @chengkai15<https://github.com/chengkai15> > > > > > > > > Thanks for the clarification. I think we are mostly aligned on the > > > > long-term direction, especially about converging to one Zephyr-based > > > > Bluetooth host and moving toward a BlueZ/Linux-style split for > > > > protected/kernel builds. > > > > > > > > For open point 2, I still prefer not to start from an external > > repository > > > > model in the main NuttX integration path. > > > > > > > > My suggestion is that the code should first be adapted into a > > > NuttX-native > > > > integration style, and then submitted directly to either nuttx.git or > > > > nuttx-apps.git, depending on the agreed layering. Fetching a large > > > external > > > > repository at build time will also bring dependency and maintenance > > > issues > > > > with other third-party code, and I do not think that is the best > > > long-term > > > > integration model for an official NuttX Bluetooth stack. > > > > > > > > In my view, if the stack is going to become part of the NuttX > Bluetooth > > > > architecture, it should be reviewed, built, tested, and maintained as > > > part > > > > of the NuttX repositories, not as an external component that is only > > > pinned > > > > by revision. > > > > > > > > Maybe you can use the current PR as a reference for the NuttX-native > > > > integration structure: top-level CONFIG_ZBLUE_ENABLED, NuttX > > > build/Kconfig > > > > integration, NuttX-style public headers, and direct integration with > > the > > > > NuttX Bluetooth driver path. The implementation details can certainly > > be > > > > changed, but I think this kind of native integration is a better > > > direction > > > > than relying on an external fetched repository. > > > > > > > > If the openvela version is adjusted in this direction and accepted by > > the > > > > community as the common upstream solution, I am willing to drop my > > > current > > > > PR and help with that effort. My goal is not to keep my own patch, > but > > to > > > > help NuttX get a complete and maintainable Bluetooth stack. > > > > > > > > — > > > > Reply to this email directly, view it on GitHub< > > > > > > > > > > https://github.com/apache/nuttx/pull/20686?email_source=notifications&email_token=ABDILOITAS5PRPRBASVZXOD5WLAN7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNBYG44DCMJZHE32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-6487811997 > > > >, > > > > or unsubscribe< > > > > > > > > > > https://github.com/notifications/unsubscribe-auth/ABDILONP3W2NPDI7EX4JEGT5WLAN7AVCNFSNUABFKJSXA33TNF2G64TZHMZDEOBRGAZTENZTHNEXG43VMU5TKOBWG4ZTIMBYG4Z2C5QC > > > > >. > > > > You are receiving this because you were mentioned.Message ID: > > > > <apache/nuttx/pull/20686/[email protected]> > > > > > > > > > > > > > > #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > > > > This e-mail and its attachments contain confidential information from > > > > XIAOMI, which is intended only for the person or entity whose address > > is > > > > listed above. Any use of the information contained herein in any way > > > > (including, but not limited to, total or partial disclosure, > > > reproduction, > > > > or dissemination) by persons other than the intended recipient(s) is > > > > prohibited. If you receive this e-mail in error, please notify the > > sender > > > > by phone or email immediately and delete it!******/# > > > > > > > > > >
