simbit18 commented on code in PR #17583: URL: https://github.com/apache/nuttx/pull/17583#discussion_r2657520721
########## Documentation/security.rst: ########## @@ -0,0 +1,482 @@ +======== +Security +======== + +.. toctree:: + +Known vulnerabilities +===================== + +Apache NuttX RTOS vulnerabilities are labelled with CVE (Common +Vulnerabilities and Exposures) identifiers. List of known, responsibly +disclosed, and fixed vulnerabilities are publicly available online at +`CVE.ORG <https://www.cve.org/CVERecord/SearchResults?query=nuttx>`_. +Offline bundled version is located at the bottom of this page in the +`NuttX CVEs`_ section. + + +Not security vulnerabilities +============================ + +Apache NuttX RTOS is highly portable to over 15 different CPU architectures, +including microcontrollers with as tiny memory resources as single kilobytes +of RAM/Flash memory. Putting additional checks outside a generic nature would +dramatically impact final firmware performance and size. +**Function parameters and incoming data validation rests on the custom +application/firmware developer.** + +Special care should be taken when handling: + + * syscalls. + * pointers (always set to NULL before and after use). + * structures (always initialize with ``{0}`` before use). + * user controllable data (type and size). + * network data. + * dynamically allocated buffers. + +.. note:: + If you find a generic problem in existing code base that + may impact Confidentiality, Integrity, or Availability (i.e. information + leak, denial of service, remote code execution) and is not your own custom + application specific, please send us a security report. + + +Security Issues Handling +======================== + +Security related issues are handled in compliance with +`The Apache Security Team Guide <https://www.apache.org/security/>`_ +and `Apache Committers Security Guide +<https://www.apache.org/security/committers.html>`_. +Please read these documents carefully before submitting and/or +handling a security vulnerabilities. Below is an extract of information. + +.. warning:: + Do not enter details of security vulnerabilities in a project's public + bug tracker, issues, or pull requests. Do not make information about + the vulnerability public until it is formally announced at the end + of this process. Messages associated with any commits should not make + any reference to the security nature of the commit. + + +1. Reporting: + + 1. Please report potential security vulnerabilities over email to + [email protected] and [email protected] **before disclosing + them in any public form**. This enables responsible disclosure by + providing a fix for everyone impacted before details are made public. + + 2. Please send one plain-text, unencrypted, email for each vulnerability + you are reporting. We may ask you to resubmit your report if you send + it as an image, movie, HTML, or PDF attachment when you could as easily + describe it with plain text. + + 3. Do not enter details of security vulnerabilities in a project's public + bug tracker, issues, or pull requests. **Do not make information about + the vulnerability public until it is formally announced at the end + of this process.** Messages associated with any commits should not make + any reference to the security nature of the commit. + + 4. Security fixes are usually part of the standard release cycle, but for + urgent cases special patch releases may be created to address the issue. + In order to keep this process smooth please provide us with as much + details as possible. **Reproducible examples, proof-of-concept code, + but most importantly fix patches are more than welcome.** + + 5. There are problems that we are well aware of, and have been reported + to us many times, but we do not classify as a security vulnerability, see + `Not security vulnerabilities`_ for details. + Please consider reporting them as Issue or Pull Request on GitHub instead. + + 6. The project team sends an e-mail to the original reporter to acknowledge + the report, with a copy to the relevant security mailing list. + +2. Investigation: + + 1. The project team investigates the report and either rejects or accepts + it. + + 2. Project team members may share information about the vulnerability + with domain experts (including colleagues at their employer) at the + discretion of the project's security team, providing that they make + clear that the **information is not for public disclosure.** + + 3. If the project team rejects the report, the team writes to the reporter + to explain why, with a copy to the relevant security mailing list. + + 4. If the project team accepts the report, the team writes to the reporter + to let them know that they have accepted the report and that they are + working on a fix or validating fix provided by the reporter. + + +3. The Fix: + + 1. The project team agrees on a fix on their private list. + + 2. The project team requests a CVE (Common Vulnerabilities and Exposures) + ID from the internal portal, https://cveprocess.apache.org. + Apache Security Team can help determine if a report requires multiple + CVE IDs or if multiple reports should be merged under a single CVE ID. + CVE ID can be shared with the reporter. + + 3. The project team documents the details of the vulnerability and the fix + on the internal portal. The portal generates draft announcement texts. + For an example of an announcement see Tomcat's announcement of + CVE-2008-2370. The level of detail to include in the report is a matter + of judgement. Generally, reports should contain enough information to + enable people to assess the risk the vulnerability poses for their own + system, and no more. **Announcements do not normally include steps + to reproduce the vulnerability.** + + 4. Optionally CVE can be set into the REVIEW state to request a review from + the Apache Security team. Discussion is possible using the "comment" + feature which also sends the comments to the private mailing list(s). + + 5. The project team provides the reporter with a copy of the fix and the + draft vulnerability announcement for comment. + + 6. The project team agrees on the fix, the announcement, and the release + schedule with the reporter. If the reporter is unresponsive in a + reasonable timeframe this should not block the project team from moving + to the next steps, particularly if an issue is of high severity/impact. + + 7. The project team commits the fix **without making any reference that + the commit relates to a security vulnerability.** + + 8. The project team creates a release that includes the fix. + +4. Public announcement: + + 1. After (or at the same time as) the release announcement, the project + team announces the vulnerability and the fix. CVE status is set to READY + in the internal portal, that is also used to send emails. + **This is the first point that any information regarding the + vulnerability is made public.** The vulnerability announcement should + be sent to the following destinations: + + a. the same destinations as the release announcement. + b. the vulnerability reporter. + c. the project's security list (or [email protected] if + the project does not have a dedicated security list). + d. [email protected] (subscription not required). + + 2. The project team updates the project's security pages. + + +NuttX CVEs +========== + +CVE-2025-48769 +-------------- + +* Title: fs/vfs/fs_rename: use after free. +* Published: 2026-01-01. +* Affected versions: >= 7.20 , < 12.11.0. +* Fixed in versions: 12.11.0. +* Type: `CWE-416 Use After Free <https://cwe.mitre.org/data/definitions/416.html>`_. +* Credits: + + * Finder: Liu, Richard Jiayang <[email protected]>. + * Remediation developer: Liu, Richard Jiayang <[email protected]>. + * Coordinator: Arnout Engelen <[email protected]>. + * Coordinator: Tomek CEDRO <[email protected]>. + * Remediation reviewer: Xiang Xiao <[email protected]>. + * Remediation reviewer: Jiuzhu Dong <[email protected]>. + +* References: + + * https://www.cve.org/CVERecord?id=CVE-2025-48769. + * http://www.openwall.com/lists/oss-security/2025/12/31/11. + * https://github.com/apache/nuttx/pull/16455. + * https://lists.apache.org/thread/7m83v11ldfq7bvw72n9t5sccocczocjn. + +Use After Free vulnerability was discovered in fs/vfs/fs_rename code of the +Apache NuttX RTOS, that due recursive implementation and single buffer use by +two different pointer variables allowed arbitrary user provided size buffer +reallocation and write to the previously freed heap chunk, that in specific +cases could cause unintended virtual filesystem rename/move operation results. +This issue affects Apache NuttX RTOS: from 7.20 before 12.11.0. Users of +virtual filesystem based services with write access especially when exposed +over the network (i.e. FTP) are affected and recommended to upgrade to +version 12.11.0 that fixes the issue. + +CVE-2025-48768 +-------------- + +* Title: fs/inode: fs_inoderemove root inode removal. +* Published: 2026-01-01. +* Affected versions: >= 10.0.0 , < 12.10.0. +* Fixed in version: 12.10.0. +* Type: `CWE-763 Release of Invalid Pointer or Reference <https://cwe.mitre.org/data/definitions/763.html>`_. +* Credits: + + * Finder: Liu, Richard Jiayang <[email protected]>. + * Remediation developer: Liu, Richard Jiayang <[email protected]>. + * Coordinator: Arnout Engelen <[email protected]>. + * Coordinator: Tomek CEDRO <[email protected]>. + * Remediation reviewer: Alan Carvalho de Assis <[email protected]>. + * Remediation reviewer: Tomek CEDRO <[email protected]>. + * Remediation reviewer: Xiang Xiao <[email protected]>. + * Remediation reviewer: Jiuzhu Dong <[email protected]>. + +* References: + + * https://www.cve.org/CVERecord?id=CVE-2025-48768. + * http://www.openwall.com/lists/oss-security/2025/12/31/10. + * https://github.com/apache/nuttx/pull/16437. + * https://lists.apache.org/thread/nwo1kd08b7t3dyz082q2pghdxwvxwyvo. + +Release of Invalid Pointer or Reference vulnerability was discovered in +fs/inode/fs_inoderemove code of the Apache NuttX RTOS that allowed root +filesystem inode removal leading to a debug assert trigger (that is disabled +by default), NULL pointer dereference (handled differently depending on the +target architecture), or in general, a Denial of Service. This issue affects +Apache NuttX RTOS: from 10.0.0 before 12.10.0. Users of filesystem based +services with write access that were exposed over the network (i.e. FTP) +are affected and recommended to upgrade to version 12.10.0 that fixes +the issue. + +CVE-2025-47869 +-------------- + +* Title: examples/xmlrpc: Fix calls buffers size. +* Published: 2025-06-16. +* Affected versions: >= 6.22 , < 12.9.0. +* Fixed in version: 12.9.0. +* Type: `CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer <https://cwe.mitre.org/data/definitions/119.html>`_. +* Credits: + + * Reporter: Chánh Phạm <[email protected]>. + * Remediation developer: Arnout Engelen <[email protected]>. + * Coordinator: Arnout Engelen <[email protected]>. + * Coordinator: Tomek CEDRO <[email protected]>. + * Remediation reviewer: Alan Carvalho de Assis <[email protected]>. + * Remediation reviewer: Alin Jerpelea <[email protected]>. + * Remediation reviewer: Lee, Lup Yuen <[email protected]>. + * Remediation reviewer: Xiang Xiao <[email protected]>. + * Remediation reviewer: JianyuWang <[email protected]>. + +* References: + + * https://www.cve.org/CVERecord?id=CVE-2025-47869. + * http://www.openwall.com/lists/oss-security/2025/06/14/2. + * https://github.com/apache/nuttx-apps/pull/3027. + * https://lists.apache.org/thread/306qcqyc3bpb2ozh015yxjo9kqs4jbvj. + +Improper Restriction of Operations within the Bounds of a Memory Buffer +vulnerability was discovered in Apache NuttX RTOS apps/exapmles/xmlrpc +application. In this example application device stats structure that stored +remotely provided parameters had hardcoded buffer size which could lead to +buffer overflow. Structure members buffers were updated to valid size of +CONFIG_XMLRPC_STRINGSIZE+1. This issue affects Apache NuttX RTOS users that +may have used or base their code on example application as presented in +releases from 6.22 before 12.9.0. Users of XMLRPC in Apache NuttX RTOS are +advised to review their code for this pattern and update buffer sizes +as presented in the version of the example in release 12.9.0. + +CVE-2025-47868 +-------------- + +* Title: tools/bdf-converter.: tools/bdf-converter: Fix loop termination + condition. +* Published: 2025-06-16. +* Affected versions: >= 6.9 , < 12.9.0. +* Fixed in version: 12.9.0. +* Type: + + * `CWE-787 Out-of-bounds Write <https://cwe.mitre.org/data/definitions/787.html>`_. + * `CWE-122 Heap-based Buffer Overflow <https://cwe.mitre.org/data/definitions/122.html>`_. + +* Credits: + + * Finder: Chánh Phạm <[email protected]>. + * Remediation developer: Nathan Hartman <[email protected]>. + * Coordinator: Arnout Engelen <[email protected]>. + * Coordinator: Tomek CEDRO <[email protected]> + * Remediation reviewer: Alan Carvalho de Assis <[email protected]>. + * Remediation reviewer: Alin Jerpelea <[email protected]>. + * Remediation reviewer: Lee, Lup Yuen <[email protected]>. + * Remediation reviewer: Nathan Hartman <[email protected]>. + * Remediation reviewer: simbit18 <??>. Review Comment: Hi @cederom Simone Falsetti [email protected] -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
