Hi, Tomek, Let me put it this way: I'm not going to make promises or speeches about security. Let's let actions do the talking. If PR #20686 https://github.com/apache/nuttx/pull/20686 gets merged, I will take ownership of all CVE issues related to this code going forward. Would that work for you?
BRs, Tomek CEDRO <[email protected]> 于2026年10月29日周四 20:36写道： > No Anchao, we have long backlog of security issues which are handled > by usually one or two overwhelmed people, your single help is most > welcome and appreciated, but it was not here for last ~2 years, and > this is real problem for us, thus Alan as the one who reported and > fixed the security issues recently can use this as an argument, > because he knows how the process looks like himself. > > Here are hints on how to approach: > https://nuttx.apache.org/docs/latest/security.html > > In my other reply I also mentioned security and maintenance as the > weak points of your approach - to take someone else code and then > maintain it yourself forever - other people also tell you this is not > the good way.. only you seem not to notice it sorry. > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > On Thu, Oct 29, 2026 at 1:29 PM chao an <[email protected]> wrote: > > > > Alin, > > > > Apologies, > > > > Alan, I've spent a lot of time and sent many emails on this topic over > the > > past days, and I find the discussion keeps circling back to points that I > > thought were already addressed. No one seems to be engaging with the > actual > > question of how to move NuttX's Bluetooth support forward. I'd appreciate > > it if we could stop revisiting the CVE argument — security is an ongoing > > responsibility for any code we maintain, and it's not unique to this > > contribution. > > > > BRs, > > > > Alin Jerpelea <[email protected]> 于2026年10月29日周四 20:22写道： > > > > > 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!******/# > > > > > > > > > > > > > > > > > > > > > > > > > >
