Upgrade to Zephyr 4.4.2 and bump mbedtls, tf-psa-crypto, fatfs - #516
Open
nateinaction wants to merge 3 commits into
Open
Upgrade to Zephyr 4.4.2 and bump mbedtls, tf-psa-crypto, fatfs#516nateinaction wants to merge 3 commits into
nateinaction wants to merge 3 commits into
Conversation
Bump the west manifest and the lib/zephyr-workspace/zephyr submodule from v4.4.1 to v4.4.2, a 197-commit security and bugfix release on the v4.4 branch. No module pins change. The only revision that moved in upstream's west.yml between the tags is hal_espressif, which this trimmed manifest does not import; all ten modules we do pin (cmsis, cmsis_6, hal_rpi_pico, hal_st, picolibc, mbedtls, tf-psa-crypto, mcuboot, fatfs, loramac-node) still match v4.4.2's manifest exactly. Of note for this deployment, 4.4.2 carries a MCUboot Kconfig fix for the RAM-revert confirmed-image path (c219dde148e), which touches the OTA swap logic. Builds: make build and make build-mcuboot both clean, console still disabled. Bootloader flash 7.30%, RAM 3.31%.
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughSummary by CodeRabbit
WalkthroughThe change updates the Zephyr subproject pointer and west manifest revisions for Zephyr, mbedTLS, TF-PSA-Crypto, and FatFs. ChangesZephyr dependency updates
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This change updates Zephyr and related dependency versions without introducing an identified merge-blocking correctness or production risk; no actionable merge-blocking risk remains after normal checks and review. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Description checkExplanation The description provides a detailed change summary, explains the rationale for each dependency update, documents verification results, and identifies the remaining OTA swap test. It does not reproduce all template sections, such as related issues and the checklist, but the core required information is present. Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.) Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Take Mbed TLS 4.1.1 and TF-PSA-Crypto 1.1.1, the revisions Zephyr's v4.4-branch already moved to after tagging 4.4.2. This is the only module movement on the stable branch, so it is what 4.4.3 will ship; taking it now keeps us on the tested combination rather than ahead of it. TF-PSA-Crypto 1.1.1 carries six CVEs. None reach either image as configured, so this is not an urgent fix: - CVE-2026-50587 (RSA PKCS#1 v1.5 decryption side channel), RSA key generation timing: we do no private-key operations and generate no keys on device. MCUboot verifies with an RSA-2048 public key under PSS. - CVE-2026-50584 (ChaCha20 counter wrap), CVE-2026-54434 (x25519 Everest low-order point): neither primitive is enabled. - CVE-2026-54435 (ECC scalar multiplication side channel), CVE-2026-50583 (1-byte overread parsing a malformed ECC public key): no ECC is compiled in. The application enables only HMAC and SHA-256 (prj.conf), the bootloader only RSA-PSS verify and SHA-256. Sizes are unchanged in both images, consistent with the changed code sitting entirely in paths we do not compile.
Unlike the crypto bump, this moves fatfs off the revision Zephyr 4.4.2 pins. The fixes landed in the Zephyr FatFs tree in July 2026 but did not make the 4.4.2 release and are not on v4.4-branch, so waiting for 4.4.3 would not pick them up. Our previous pin dates to October 2025 and is a pristine ChaN R0.16 with none of them applied. Three are mount-time validation, which is the reason to take this. The flight filesystem is FAT with exFAT enabled (prj.conf), and the realistic trigger here is not an attacker-supplied volume but a superblock torn by a hard reset -- the same corruption class that motivated the boot count hardening in #470. Today a malformed BPB faults; with these it is rejected at mount, and CONFIG_FS_FATFS_MOUNT_MKFS reformats and recovers. - CVE-2026-6682: BPB_FATSz32 times the FAT count overflowed a DWORD, laying the data region inside the FAT. Now capped before the multiply. - CVE-2026-6683 (exFAT): a BPB reporting zero clusters made sync_fs() divide by zero on first write or unmount. Rejected at mount instead. - CVE-2026-6687 (exFAT): f_getlabel() looped over an unvalidated on-disk count and overran the caller's buffer. Clamped to the 11-char maximum. The fourth, CVE-2026-6686, zeroes the range exposed when f_lseek() extends a file past end-of-file; that range previously read back stale flash contents. The fifth, CVE-2026-6685, upstream documents as a readability change rather than a real fix. The six commits touch only ff.c and documentation, so there is no Zephyr-side glue to adapt. Costs 280 bytes of flash (64.67% -> 64.70%) for the fill_zero helper; RAM is unchanged.
nateinaction
changed the title
nateinaction
marked this pull request as ready for review
August 31, 2026 14:50
nateinaction
enabled auto-merge (squash)
August 31, 2026 14:51
Mikefly123
self-requested a review
September 2, 2026 04:46
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the west manifest and the
lib/zephyr-workspace/zephyrsubmodule from v4.4.1 to v4.4.2, a 197-commit security and bugfix release on the v4.4 branch, then moves three module pins.Three commits, reviewable independently.
1. Zephyr 4.4.2
Of the ten modules this trimmed manifest imports, none of their revisions moved between the two tags — the only change in upstream's
west.ymlishal_espressif, which we don't import. So the upgrade itself is one manifest line plus the submodule pointer.4.4.2 includes
c219dde148e modules: mcuboot: kconfig: Fix RAM revert image confirmed image, which touches OTA swap logic. Given this repo's history with swap behavior, that's the piece worth exercising on hardware.2. mbedtls + tf-psa-crypto → Mbed TLS 4.1.1 / TF-PSA-Crypto 1.1.1
These are the revisions Zephyr's
v4.4-branchmoved to after tagging 4.4.2 — the only module movement on the stable branch, so this is what 4.4.3 will ship. Taking it now keeps us on the tested combination rather than ahead of it.TF-PSA-Crypto 1.1.1 carries six CVEs, but none reach either image as configured, so this is housekeeping rather than an urgent fix. The application enables only HMAC and SHA-256 (
prj.conf:94-96); the bootloader only RSA-PSS verify with SHA-256. The CVEs are in RSA PKCS#1 v1.5 decryption, RSA key generation, ChaCha20, x25519/Everest ECDH, ECC scalar multiplication, and ECC public-key parsing — no ECC, no ChaCha, no private-key operations, no on-device keygen. Image sizes are unchanged, consistent with that analysis.3. fatfs →
4f60a12c(ahead of the manifest)This one is a deliberate divergence and the reason it's worth merging now rather than waiting.
Five FatFs CVEs were fixed in July 2026 but did not make 4.4.2, and are not on
v4.4-branch— 4.4.3 won't pick them up either. Our pin dates to October 2025 and is a pristine ChaN R0.16 with none of them applied (verified:MIN_EXFAT,MIN_VOLUME,fill_zeroall absent).Three are mount-time validation, and the flight filesystem is FAT with exFAT enabled:
BPB_FATSz32× FAT count overflowed a DWORD, laying the data region inside the FATsync_fs()divides by zero on first write or unmountf_getlabel()looped over an unvalidated on-disk count, overrunning the caller's bufferThe realistic trigger here isn't an attacker-supplied volume — it's a superblock torn by a hard reset, the same corruption class that motivated the boot-count hardening in #470. Today a malformed BPB faults; with these patches it's rejected at mount, and
CONFIG_FS_FATFS_MOUNT_MKFS=yreformats and recovers.A fourth, CVE-2026-6686, zeroes the range exposed when
f_lseek()extends a file past EOF, which previously read back stale flash contents. The fifth (CVE-2026-6685) upstream documents as a readability change, not a fix.The six commits touch only
ff.cand docs, so there's no Zephyr-side glue to adapt.Verification
west update— all projects at their expected revisionsmake build— clean. Application FLASH 64.70% (675,560 B, +280 B from fatfsfill_zero), RAM 56.70% (unchanged)make check-console-disabled— OK, console still off so the downlink stays frames-onlymake build-mcuboot— clean. Bootloader FLASH 8.96% (93,516 B), RAM 8.97%Still to do before this leaves draft