mt7925e: fix buffer overflow in mt76_connac2_load_patch()

[l33tm4st3r]

Fix strnlen buffer overflow in mt76_connac2_load_patch() function when loading firmware for MediaTek MT7925 WiFi chipset on kernel 6.19.0-rc1.

The issue occurs at line 3128 where dev_info() uses format specifier %.16s on a 16-byte buffer (mt76_connac2_patch_hdr.build_date[16]). Without a guaranteed null-terminator within the buffer bounds, the fortified strnlen function detects a read beyond buffer boundaries.

Error Message

strnlen: detected buffer overflow: 17 byte read of buffer size 16
kernel BUG at lib/string_helpers.c:1043!
Oops: invalid opcode: 0000 [#1] SMP NOPTI

Root Cause

The format specifier %.16s specifies the maximum number of characters to read as 16, but the buffer build_date[16] only has 16 bytes total. If the string is not null-terminated within those 16 bytes, strnlen will attempt to read byte 17, causing buffer overflow detection on kernels with _FORTIFY_SOURCE enabled.

Solution

Change the format specifier from %.16s to %.15s. This ensures we never read beyond the 16-byte buffer bounds.

This approach is consistent with the similar structure mt76_connac2_fw_trailer which has a 15-byte build_date field and uses %.15s format specifier in the mt76_connac2_load_ram() function (line 3051).

Testing

• Kernel: 6.19.0-rc1-1-cachyos-rc
• Device: MediaTek MT7925
• Regression: From 6.18.2 (works fine)
• Impact: Kernel panic on boot → System boots successfully

Files Changed

• mt76_connac_mcu.c: Line 3127, format specifier %.16s → %.15s

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[l33tm4st3r]

This PR is ready for review. It fixes a critical buffer overflow in mt76_connac2_load_patch() affecting MT7925 on kernel 6.19.0-rc1. The fix is a single line change consistent with similar code patterns in the same file. Please review when available.

[Djfe]

see
https://patchwork.kernel.org/project/linux-wireless/patch/20251217222622.8161-1-spasswolf@web.de/

and
https://lore.kernel.org/all/CABXGCsMeAZyNJ-Axt_CUCXgyieWPV3rrcLpWsveMPT8R0YPGnQ@mail.gmail.com/

[l33tm4st3r]

see https://patchwork.kernel.org/project/linux-wireless/patch/20251217222622.8161-1-spasswolf@web.de/

and https://lore.kernel.org/all/CABXGCsMeAZyNJ-Axt_CUCXgyieWPV3rrcLpWsveMPT8R0YPGnQ@mail.gmail.com/

Thanks for pointing this out. I see there's already a more comprehensive fix in the kernel mailing list by Bert Karwatzki. That approach using strscpy() and strim() is more robust. We can wait for that to be merged in the kernel first, or I can update this PR to match that solution.

[Djfe]

PRs in this repo are not merged.
Everything is handled over the Linux wireless mailing list

[l33tm4st3r]

Thanks for the guidance. I wasn't aware that patches for this project go through the Linux wireless mailing list rather than GitHub PRs. I'll close this PR and submit the patch to linux-wireless@vger.kernel.org using the proper mailing list process. Appreciate the clarification!

[Djfe]

you could also comment under the existing mail threads instead.
I mean why post a similar solution to the same problem when someone else did it just three days ago :)
You could test the patch and add your
Tested-by: l33tm4st3r <fransm@gmail.com>
You are expected to use your real name though. Contributions to the kernel as well as OpenWrt are only accepted with real names not with usernames.