From: Greg KH <gregkh@linuxfoundation.org>
To: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Cc: jirislaby@kernel.org, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] tty: vt: fix memory leak in vc_allocate()
Date: Thu, 30 Jul 2026 16:25:51 +0200 [thread overview]
Message-ID: <2026073028-icing-dallying-9229@gregkh> (raw)
In-Reply-To: <88f9ac58-8079-415d-902c-3b9455a9d17c@stu.xidian.edu.cn>
On Thu, Jul 23, 2026 at 06:45:23PM +0800, Mingyu Wang wrote:
>
> > How was this tested? And how can this ever fail given this happens at
> > early boot time, right?
> >
>
> Hi Greg,
>
> Thank you for the review.
>
> Regarding how it can fail:
> While vc_allocate() is indeed heavily used during early boot, it is also
> reachable at runtime when dynamically allocating new virtual consoles (e.g.,
> via the VT_ACTIVATE ioctl). The failure we observed happened at runtime
> because our fuzzing environment enables kernel fault injection (failslab).
> The fuzzer intentionally forced the kzalloc() for the screen buffer to fail,
> which exposed this specific error-handling path.
>
> Regarding testing:
> This issue was discovered using DevGen (our automated virtual device
> modeling fuzzer on QEMU). While we do not have a standalone C reproducer to
> run a dynamic runtime test, the fix was derived directly from dynamic
> execution evidence: we cross-analyzed the precise kmemleak backtraces and
> the fuzzer's execution logs.
You need to document the tools you use as per our documentation. Please
do so when you resend this.
thanks,
gre gk-h
prev parent reply other threads:[~2026-07-30 16:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 7:05 [PATCH] tty: vt: fix memory leak in vc_allocate() Mingyu Wang
2026-07-23 7:15 ` Greg KH
2026-07-23 10:45 ` Mingyu Wang
2026-07-30 14:25 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026073028-icing-dallying-9229@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=25181214217@stu.xidian.edu.cn \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.