If the screen buffer allocation fails in vc_allocate(), the error handling
path jumps to `err_free`. However, this path fails to release the unicode
screen map attached to `vc->uni_pagedict_loc`.

During the early stages of vc_allocate(), the unicode screen map is either
newly allocated via con_set_default_unimap() or shares the default unicode
map from a previously initialized console (which increments its refcount).
If the subsequent kzalloc() for the screen buffer fails, the err_free path
frees the vc structure but leaves the attached uni_pagedict with an
elevated refcount. This results in a memory leak if that console is later
deallocated.

Fix this by calling con_free_unimap(vc) in the err_free path before
kfree(vc). This safely decrements the refcount and releases the dictionary
memory if this was the last reference.

Fixes: 34902b7f2754 ("tty: vt, get rid of weird source code flow")
Cc: stable@vger.kernel.org
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
---
 drivers/tty/vt/vt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 8f467b22b799..4bac89ea968a 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1134,6 +1134,7 @@ int vc_allocate(unsigned int currcons)	/* return 0 on success */
 	return 0;
 err_free:
 	visual_deinit(vc);
+	con_free_unimap(vc);
 	kfree(vc);
 	vc_cons[currcons].d = NULL;
 	return err;
-- 
2.34.1

On Thu, Jul 23, 2026 at 03:05:30PM +0800, Mingyu Wang wrote:
> If the screen buffer allocation fails in vc_allocate(), the error handling
> path jumps to `err_free`. However, this path fails to release the unicode
> screen map attached to `vc->uni_pagedict_loc`.
> 
> During the early stages of vc_allocate(), the unicode screen map is either
> newly allocated via con_set_default_unimap() or shares the default unicode
> map from a previously initialized console (which increments its refcount).
> If the subsequent kzalloc() for the screen buffer fails, the err_free path
> frees the vc structure but leaves the attached uni_pagedict with an
> elevated refcount. This results in a memory leak if that console is later
> deallocated.
> 
> Fix this by calling con_free_unimap(vc) in the err_free path before
> kfree(vc). This safely decrements the refcount and releases the dictionary
> memory if this was the last reference.
> 
> Fixes: 34902b7f2754 ("tty: vt, get rid of weird source code flow")
> Cc: stable@vger.kernel.org
> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>

How was this tested?  And how can this ever fail given this happens at
early boot time, right?

thanks,

greg k-h

> 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.

The kmemleak traces clearly showed that when fault injection intercepted 
the screen buffer allocation, the execution jumped to `err_free`, 
permanently bypassing the cleanup of the unicode screen map (which had 
its refcount incremented earlier).

The patch has been compile-tested. Since con_free_unimap() safely checks 
for a NULL pointer internally, adding it to the err_free path ensures 
the elevated refcount is safely dropped without introducing regressions.

I hope this clarifies the context of the bug and the fix.

Best regards,
Mingyu Wang