Hi Handa-san,
On Thu, Nov 17, 2022 at 4:32 PM Tetsuo Handa penguin-kernel@i-love.sakura.ne.jp wrote:
A kernel built with syzbot's config file reported that
scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2))
causes uninitialized "save" to be copied.
Signed-off-by: Tetsuo Handa penguin-kernel@I-love.SAKURA.ne.jp
Thanks for your patch, which is now commit a6a00d7e8ffd78d1 ("fbcon: Use kzalloc() in fbcon_prepare_logo()") in v6.1-rc7, and which is being backported to stable.
--- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -577,7 +577,7 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct fb_info *info, if (scr_readw(r) != vc->vc_video_erase_char) break; if (r != q && new_rows >= rows + logo_lines) {
save = kmalloc(array3_size(logo_lines, new_cols, 2),
save = kzalloc(array3_size(logo_lines, new_cols, 2), GFP_KERNEL); if (save) { int i = min(cols, new_cols);
The next line is:
scr_memsetw(save, erase, array3_size(logo_lines, new_cols, 2));
So how can this turn out to be uninitialized later below?
scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2));
What am I missing?
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On 2022/12/15 18:36, Geert Uytterhoeven wrote:
The next line is:
scr_memsetw(save, erase, array3_size(logo_lines, new_cols, 2));So how can this turn out to be uninitialized later below?
scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2));What am I missing?
Good catch. It turned out that this was a KMSAN problem (i.e. a false positive report).
On x86_64, scr_memsetw() is implemented as
static inline void scr_memsetw(u16 *s, u16 c, unsigned int count) { memset16(s, c, count / 2); }
and memset16() is implemented as
static inline void *memset16(uint16_t *s, uint16_t v, size_t n) { long d0, d1; asm volatile("rep\n\t" "stosw" : "=&c" (d0), "=&D" (d1) : "a" (v), "1" (s), "0" (n) : "memory"); return s; }
. Plain memset() in arch/x86/include/asm/string_64.h is redirected to __msan_memset() but memsetXX() are not redirected to __msan_memsetXX(). That is, memory initialization via memsetXX() results in KMSAN's shadow memory being not updated.
KMSAN folks, how should we fix this problem? Redirect assembly-implemented memset16(size) to memset(size*2) if KMSAN is enabled?
linux-stable-mirror@lists.linaro.org
-
Geert Uytterhoeven -
Tetsuo Handa