Hi, Let's take this discussion to GitHub. If you have any further comments, please reply on PR #20686 https://github.com/apache/nuttx/pull/20686. I won't be responding further on this mailing list.
BRs, chao an <[email protected]> 于2026年10月29日周四 20:42写道： > 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!******/# >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> >
