This reverts commit a6a00d7e8ffd78d1cdb7a43f1278f081038c638f.
The syzbot report turned out to be a false possitive, caused by a KMSAN
problem. Indeed, after allocating the buffer, it is fully initialized
using scr_memsetw(). Hence there is no point in allocating zeroed
memory, while this does incur some overhead.
Closes: https://lore.kernel.org/r/CAMuHMdUH4CU9EfoirSxjivg08FDimtstn7hizemzyQzYeq6b6g@mail.gmail.com/
Signed-off-by: Geert Uytterhoeven <[email protected]>
---
drivers/video/fbdev/core/fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 8e76bc246b3871b0..0246948f3c81a7a6 100644
--- 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 = kzalloc(array3_size(logo_lines, new_cols, 2),
+ save = kmalloc(array3_size(logo_lines, new_cols, 2),
GFP_KERNEL);
if (save) {
int i = min(cols, new_cols);
--
2.34.1
On 2023/07/25 2:03, Geert Uytterhoeven wrote:
> The syzbot report turned out to be a false possitive, caused by a KMSAN
> problem. Indeed, after allocating the buffer, it is fully initialized
> using scr_memsetw(). Hence there is no point in allocating zeroed
> memory, while this does incur some overhead.
I suggest using below description, for this problem was reported by me
using a kernel built with syzbot's config file (i.e. syzbot is irrelevant).
Commit a6a00d7e8ffd ("fbcon: Use kzalloc() in fbcon_prepare_logo()") is
redundant, for the root cause that resulted in a false positive was fixed
by commit 27f644dc5a77 ("x86: kmsan: use C versions of memset16/memset32/
memset64").