Re: [PATCH] tty: vt: fix memory leak in vc_allocate()

> 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