Fix out-of-bounds write in drawChar() classic glcdfont path#807
Merged
moononournation merged 1 commit intoJul 14, 2026
Merged
Conversation
Owner
|
changing writePixelPreclipped to writePixel is not a good idea, please pay more effort to make it. |
The built-in glcdfont path checked only the maximum text bounds before calling writePixelPreclipped. A partially visible character starting above or left of the text area could therefore pass negative coordinates to canvas implementations that trust their caller and index the framebuffer directly. Add the missing minimum-text-bound checks in the column and row loops. This keeps the direct preclipped write path for visible pixels while skipping pixels outside the top or left text boundary. Constraint: writePixelPreclipped intentionally performs no coordinate validation. Rejected: Route every glyph pixel through writePixel | maintainer requested preserving the preclipped fast path. Confidence: high Scope-risk: narrow Directive: Keep all coordinates validated against both text bounds before preclipped writes. Tested: real Arduino_GFX/Arduino_Canvas host harness; partially visible negative cursor has 0 invalid writes; visible and canvas-clipped framebuffer hashes match the prior safe output; custom text-bound clipping verified; git diff --check Not-tested: physical display hardware
ecc338f to
23a4da0
Compare
Contributor
Author
|
Updated in 23a4da0. The glyph path now keeps writePixelPreclipped() and adds the missing _min_text_x/_min_text_y checks alongside the existing maximum-bound checks. The real Canvas harness reports zero invalid writes for the negative-cursor cases, while fully visible and canvas-clipped framebuffer hashes remain unchanged. I also corrected the PR description to match the measured results. |
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
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.
Problem
The classic built-in glcdfont branch in
Arduino_GFX::drawChar()sends pixels directly towritePixelPreclipped(). Its loops checked_max_text_xand_max_text_y, but not the corresponding minimum text bounds.When a partially visible character starts above or left of the text area, negative coordinates can therefore reach canvas implementations that index their framebuffer directly and rely on the caller to have clipped them.
Fix
Add the missing
_min_text_xand_min_text_ychecks to the existing column and row conditions. Visible pixels continue to usewritePixelPreclipped()directly; only pixels outside the top or left text boundary are skipped.Verification
I built a host harness against the real repository
Arduino_G.cpp,Arduino_GFX.cpp, andArduino_Canvas.cpp, using aProbeCanvassubclass only to record coordinates before forwarding each call to the real canvas implementation.setCursor(-3, -2); print("A")made 40 preclipped writes: 13 had framebuffer offsets outside[0, 4096), and 15 more had invalid coordinates that mapped to unrelated in-buffer pixels.setCursor(-3, 5)likewise completes with 16 visible writes and zero invalid writes.(4, 5)also clips pixels against its minimum x/y values.The host harness compiles and runs successfully. Physical display hardware was not used.