Dear U-Boot Maintainers, I'm Sin Liang Lee, a member of Team Atlanta<https://team-atlanta.github.io/> from Georgia Institute of Technology, winners of DARPA's AI Cyber Challenge (AIxCC)<https://aicyberchallenge.com/>. We're reaching out to submit a vulnerability report that we identified using our system, ATLANTIS, in your project. This effort is part of DARPA's initiative to apply competition technologies to real-world open source projects.
We have built an AI-enhanced CRS (Cyber Reasoning System) for automatic vulnerability detection and repair. Using a combination of targeted fuzzing (via OSS-Fuzz infrastructure) and AI-assisted static analysis, we identified four buffer overflow vulnerabilities in the U-Boot NFS client reply parsers (net/nfs-common.c). These affect the current upstream codebase and include a signedness bypass of the mitigation introduced for CVE-2019-14193. Vulnerability Summary # Description CWE CVSS 3.1 1 Integer signedness bypass in nfs_readlink_reply() bounds check CWE-195 8.8 (High) 2 nfs_path_buff[2048] overflow via chained symlink resolution CWE-120 8.8 (High) 3 Stack buffer overflow in rpc_req_common() via oversized NFS path CWE-121 8.8 (High) 4 Fixed-size OOB read in nfs_read_reply() CWE-125 7.1 (High) Impact * BSS corruption enabling NFS server IP redirection (boot chain hijack) * Stack buffer overflow with demonstrated return address control (RCE-capable, confirmed via GDB hardware watchpoint) * Denial of Service via OOB read crash on undersized packets * Attack model: Malicious NFS server on same LAN segment (AV:A) Relationship to Prior CVEs * Vulnerability #1 exploits a signedness flaw (CWE-195) in the bounds check introduced by the CVE-2019-14193 fix (commit cf3a4f1e). The variable rlen is declared as int (signed) at line 645 of nfs-common.c, but receives a uint32_t from ntohl(). Negative values bypass the check at line 669. * Vulnerability #2 exploits a missing destination-side check that the CVE-2019-14193 fix did not address — rlen is validated against the source packet length but never against sizeof(nfs_path_buff). * Vulnerabilities #3 and #4 are in different functions (rpc_req_common and nfs_read_reply) not addressed by any prior fix. Deliverables We are providing: 1. Standalone PoCs — Docker-based, zero external dependencies. Each vulnerability has its own directory with a docker-compose.yaml: docker compose up --build 1. End-to-end chain PoC — Demonstrates the full attack chain: 10 iterations of nfs_readlink_reply() accumulating path data (11 → 1811 bytes), then nfs_mount_req() → rpc_req_common() → 724-byte stack overflow. No pre-populated shortcuts. 2. GDB verification — Hardware watchpoint proving saved return address overwritten with attacker-controlled symlink path content. 3. Proposed patches — Individual per-vulnerability diff files against net/nfs-common.c, tested with AddressSanitizer 4. Vulnerability reports — Four individual reports with root cause analysis, ASan output, CVSS scoring, and recommended fixes. Full Report & PoCs * Vulnerability 1: https://drive.google.com/drive/folders/1NkZBPb8oKyKQG0iOlrTi1ROoIZ9szWUB?usp=sharing * Vulnerability 2: https://drive.google.com/drive/folders/1B4dbPNCCtQEGZiXXUC-z1B0ESSrYf1FE?usp=sharing * Vulnerability 3: https://drive.google.com/drive/folders/1rpCMtQSGfVR15WG2FfZc6ZlrsUv7cWPE?usp=sharing * Vulnerability 4: https://drive.google.com/drive/folders/1lP7zJtcw9ALXCq56fnUHmV8q_vlRdujh?usp=sharing Could you please confirm the vulnerabilities and review the proposed patches? Thank you. Best regards, Sin Liang Lee Team Atlanta
