[Deepin-Kernel-SIG] [linux 6.18.y] [Deepin] lib/fonts: cjktty: Remove Unicode bidirectional control characters fr…#1650
Conversation
…om comments GCC's -Wbidi-chars option (enabled by default since GCC 12) detects potentially dangerous Unicode bidirectional text control characters that could be exploited in "Trojan Source" attacks (CVE-2021-42574). The font_cjk_16x16.h/font_cjk_32x32.h header files contained actual Unicode bidirectional control characters embedded within comments as glyph representations: - U+200E (LEFT-TO-RIGHT MARK) - U+200F (RIGHT-TO-LEFT MARK) - U+202C (POP DIRECTIONAL FORMATTING) - U+2069 (POP DIRECTIONAL ISOLATE) Replace these invisible control characters with their standard Unicode abbreviations (LRM, RLM, PDF, PDI) enclosed in parentheses. This preserves the documentary intent of the comments while eliminating the build failure caused by -Werror=bidi-chars. This change is necessary and appropriate because GCC 12 and later versions introduced the -Wbidi-chars warning (enabled by default) specifically to mitigate "Trojan Source" attacks as described in CVE-2021-42574. These attacks exploit Unicode bidirectional override characters to make source code appear different from how it actually executes, potentially hiding malicious logic within seemingly benign code. While the characters in this font header file are legitimately used as glyph data representations in comments rather than for malicious purposes, the compiler cannot distinguish intent and correctly flags them as a potential security risk. The kernel build system treats all warnings as errors (-Werror), causing the build to fail. By replacing the actual invisible control characters with their human-readable abbreviations (LRM for Left-to-Right Mark, RLM for Right-to-Left Mark, PDF for Pop Directional Formatting, and PDI for Pop Directional Isolate), we maintain the original documentation purpose of identifying which Unicode codepoint each glyph represents while ensuring the code compiles cleanly and passes security-focused static analysis. Link: https://www.cve.org/CVERecord?id=CVE-2021-42574 Link: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wbidi-chars Link: https://unicode.org/reports/tr9/ Signed-off-by: WangYuli <wangyl5933@chinaunicom.cn> [Only fix 16x16] (cherry picked from commit 380793f) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Reviewer's guide (collapsed on small PRs)Reviewer's GuideThis PR removes actual Unicode bidirectional control characters from comments in the CJK 16x16 font header and replaces them with human-readable abbreviations, resolving GCC -Wbidi-chars build failures while preserving the documentation intent. Flow diagram for GCC -Wbidi-chars handling after comment cleanupflowchart LR
OldSrc[font_cjk_16x16.h with bidi control characters in comments]
NewSrc[font_cjk_16x16.h with LRM/RLM/PDF/PDI abbreviations in comments]
OldSrc --> GCCWarn[GCC with -Wbidi-chars detects bidi control characters]
GCCWarn --> Werror[Kernel build with -Werror converts warning to error]
Werror --> BuildFail[Kernel build fails]
NewSrc --> GCCNoWarn[GCC with -Wbidi-chars detects no bidi control characters]
GCCNoWarn --> BuildPass[Kernel build succeeds]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Pull request overview
Removes invisible Unicode bidirectional control characters from comments in the CJK 16x16 font header to avoid GCC 12+ -Wbidi-chars warnings being promoted to errors during kernel builds, while preserving the intent of documenting the affected codepoints.
Changes:
- Replace embedded bidi control characters in
font_cjk_16x16.hcomments with readable abbreviations:(LRM),(RLM),(PDF),(PDI).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Avenger-285714 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
…om comments
GCC's -Wbidi-chars option (enabled by default since GCC 12) detects potentially dangerous Unicode bidirectional text control characters that could be exploited in "Trojan Source" attacks (CVE-2021-42574).
The font_cjk_16x16.h/font_cjk_32x32.h header files contained actual Unicode bidirectional control characters embedded within comments as glyph representations:
Replace these invisible control characters with their standard Unicode abbreviations (LRM, RLM, PDF, PDI) enclosed in parentheses. This preserves the documentary intent of the comments while eliminating the build failure caused by -Werror=bidi-chars.
This change is necessary and appropriate because GCC 12 and later versions introduced the -Wbidi-chars warning (enabled by default) specifically to mitigate "Trojan Source" attacks as described in CVE-2021-42574. These attacks exploit Unicode bidirectional override characters to make source code appear different from how it actually executes, potentially hiding malicious logic within seemingly benign code. While the characters in this font header file are legitimately used as glyph data representations in comments rather than for malicious purposes, the compiler cannot distinguish intent and correctly flags them as a potential security risk. The kernel build system treats all warnings as errors (-Werror), causing the build to fail. By replacing the actual invisible control characters with their human-readable abbreviations (LRM for Left-to-Right Mark, RLM for Right-to-Left Mark, PDF for Pop Directional Formatting, and PDI for Pop Directional Isolate), we maintain the original documentation purpose of identifying which Unicode codepoint each glyph represents while ensuring the code compiles cleanly and passes security-focused static analysis.
Link: https://www.cve.org/CVERecord?id=CVE-2021-42574
Link: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wbidi-chars
Link: https://unicode.org/reports/tr9/
[Only fix 16x16]
(cherry picked from commit 380793f)
Summary by Sourcery
Bug Fixes: