[PATCH 7.0] fbdev: fbcon: fix memory leak in error path of fbcon_do_set_font()

[PATCH 7.0] fbdev: fbcon: fix memory leak in error path of fbcon_do_set_font()

[w15303746062]

From: Mingyu Wang <25181214217@stu.xidian.edu.cn>

[ Note: This issue was discovered on the 7.0 kernel. While the current
  mainline has already been refactored to use `font_data_t` (which 
  inadvertently resolved this bug), this vulnerability still actively 
  affects the 7.0 branch and older stable trees that rely on the legacy 
  userfont logic. This patch provides a targeted fix for these stable 
  branches. ]

When fbcon_do_set_font() fails (e.g., due to a vc_resize() failure under
fault injection), it jumps to the `err_out` label to roll back the
console state.

However, the restoration of the previous font state (`p->userfont =
old_userfont`) is erroneously placed inside the `if (userfont)` block.
If the failed operation was attempting to set the default builtin font
(`userfont == 0`), the restoration is completely skipped.

This causes a state machine corruption where `p->userfont` remains `0`
while `p->fontdata` still points to the previously allocated user font
memory. Later, when the console is destroyed (e.g., via VT_DISALLOCATE),
fbcon_free_font() fails to free this memory because its `if (p->userfont)`
check fails, resulting in a memory leak caught by kmemleak:

  unreferenced object 0xffff888127ea0000 (size 33296):
    comm "syz.0.8726", pid 33224, jiffies 4297754643
    hex dump (first 32 bytes):
      a6 e4 f9 dd 00 00 00 00 00 82 00 00 01 00 00 00  ................
      d2 09 6c bf 52 8a 7d d4 ef 1d 59 16 51 86 32 bf  ..l.R.}...Y.Q.2.
    backtrace (crc 4a0a57dd):
      ___kmalloc_large_node+0xe7/0x180 mm/slub.c:5214
      __kmalloc_large_node_noprof+0x29/0x130 mm/slub.c:5232
      __do_kmalloc_node mm/slub.c:5248 [inline]
      __kmalloc_noprof+0x5fc/0x7c0 mm/slub.c:5272
      kmalloc_noprof include/linux/slab.h:954 [inline]
      fbcon_set_font+0x431/0xa60 drivers/video/fbdev/core/fbcon.c:2525
      con_font_set drivers/tty/vt/vt.c:4918 [inline]
      con_font_op+0x94d/0xe80 drivers/tty/vt/vt.c:4958
      vt_k_ioctl drivers/tty/vt/vt_ioctl.c:472 [inline]
      vt_ioctl+0x63c/0x2ee0 drivers/tty/vt/vt_ioctl.c:743

Fix this by moving the `p->userfont = old_userfont` assignment outside
the `if (userfont)` block so that the terminal state is unconditionally
and correctly restored regardless of which font setting triggered the
error.

Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed")
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
---
 drivers/video/fbdev/core/fbcon.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 666261ae59d8..a38545dc8416 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2461,8 +2461,10 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
 	p->fontdata = old_data;
 	vc->vc_font.data = old_data;
 
+	/* Unconditionally restore the previous userfont state */
+	p->userfont = old_userfont;
+
 	if (userfont) {
-		p->userfont = old_userfont;
 		if (--REFCOUNT(data) == 0)
 			kfree(data - FONT_EXTRA_WORDS * sizeof(int));
 	}
-- 
2.34.1

Re:[PATCH 7.0] fbdev: fbcon: fix memory leak in error path of fbcon_do_set_font()

[w15303746062]

Hi Helge, Simona, and all,

A gentle ping on this patch.

Since this issue was inherently resolved in the mainline tree via a recent refactor, this specific fix is intended only for the 7.0 and older stable branches where the legacy userfont logic is still present and vulnerable to this memory leak.

Could the fbdev maintainers please take a look and provide an Acked-by? This will allow the stable team to safely pick it up for the older trees.

(+Cc stable@vger.kernel.org)

Best regards,
Mingyu

At 2026-05-25 16:27:41, w15303746062@163.com wrote:
>From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>
>[ Note: This issue was discovered on the 7.0 kernel. While the current
>  mainline has already been refactored to use `font_data_t` (which 
>  inadvertently resolved this bug), this vulnerability still actively 
>  affects the 7.0 branch and older stable trees that rely on the legacy 
>  userfont logic. This patch provides a targeted fix for these stable 
>  branches. ]
>
>When fbcon_do_set_font() fails (e.g., due to a vc_resize() failure under
>fault injection), it jumps to the `err_out` label to roll back the
>console state.
>
>However, the restoration of the previous font state (`p->userfont =
>old_userfont`) is erroneously placed inside the `if (userfont)` block.
>If the failed operation was attempting to set the default builtin font
>(`userfont == 0`), the restoration is completely skipped.
>
>This causes a state machine corruption where `p->userfont` remains `0`
>while `p->fontdata` still points to the previously allocated user font
>memory. Later, when the console is destroyed (e.g., via VT_DISALLOCATE),
>fbcon_free_font() fails to free this memory because its `if (p->userfont)`
>check fails, resulting in a memory leak caught by kmemleak:
>
>  unreferenced object 0xffff888127ea0000 (size 33296):
>    comm "syz.0.8726", pid 33224, jiffies 4297754643
>    hex dump (first 32 bytes):
>      a6 e4 f9 dd 00 00 00 00 00 82 00 00 01 00 00 00  ................
>      d2 09 6c bf 52 8a 7d d4 ef 1d 59 16 51 86 32 bf  ..l.R.}...Y.Q.2.
>    backtrace (crc 4a0a57dd):
>      ___kmalloc_large_node+0xe7/0x180 mm/slub.c:5214
>      __kmalloc_large_node_noprof+0x29/0x130 mm/slub.c:5232
>      __do_kmalloc_node mm/slub.c:5248 [inline]
>      __kmalloc_noprof+0x5fc/0x7c0 mm/slub.c:5272
>      kmalloc_noprof include/linux/slab.h:954 [inline]
>      fbcon_set_font+0x431/0xa60 drivers/video/fbdev/core/fbcon.c:2525
>      con_font_set drivers/tty/vt/vt.c:4918 [inline]
>      con_font_op+0x94d/0xe80 drivers/tty/vt/vt.c:4958
>      vt_k_ioctl drivers/tty/vt/vt_ioctl.c:472 [inline]
>      vt_ioctl+0x63c/0x2ee0 drivers/tty/vt/vt_ioctl.c:743
>
>Fix this by moving the `p->userfont = old_userfont` assignment outside
>the `if (userfont)` block so that the terminal state is unconditionally
>and correctly restored regardless of which font setting triggered the
>error.
>
>Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed")
>Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>---
> drivers/video/fbdev/core/fbcon.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>index 666261ae59d8..a38545dc8416 100644
>--- a/drivers/video/fbdev/core/fbcon.c
>+++ b/drivers/video/fbdev/core/fbcon.c
>@@ -2461,8 +2461,10 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
> 	p->fontdata = old_data;
> 	vc->vc_font.data = old_data;
> 
>+	/* Unconditionally restore the previous userfont state */
>+	p->userfont = old_userfont;
>+
> 	if (userfont) {
>-		p->userfont = old_userfont;
> 		if (--REFCOUNT(data) == 0)
> 			kfree(data - FONT_EXTRA_WORDS * sizeof(int));
> 	}
>-- 
>2.34.1

Re:Re:[PATCH 7.0] fbdev: fbcon: fix memory leak in error path of fbcon_do_set_font()

[w15303746062]

From: Mingyu Wang <25181214217@stu.xidian.edu.cn>

Hi Helge, Simona, and all,

Resending this patch as a gentle reminder, since it has been a while 
from the original submission (May 25) and my previous ping (June 5).

As a quick note, since this memory leak was implicitly resolved in 
mainline via a recent refactor, this fix is specifically targeted at 
7.0 and older stable branches using the legacy userfont logic.

Could you please take a look when you have a moment? Any feedback or 
guidance on how best to proceed with this stable-only fix would be 
greatly appreciated.

Best regards,

Mingyu

>At 2026-05-25 16:27:41, w15303746062@163.com wrote:
>>From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>>
>>[ Note: This issue was discovered on the 7.0 kernel. While the current
>>  mainline has already been refactored to use `font_data_t` (which 
>>  inadvertently resolved this bug), this vulnerability still actively 
>>  affects the 7.0 branch and older stable trees that rely on the legacy 
>>  userfont logic. This patch provides a targeted fix for these stable 
>>  branches. ]
>>
>>When fbcon_do_set_font() fails (e.g., due to a vc_resize() failure under
>>fault injection), it jumps to the `err_out` label to roll back the
>>console state.
>>
>>However, the restoration of the previous font state (`p->userfont =
>>old_userfont`) is erroneously placed inside the `if (userfont)` block.
>>If the failed operation was attempting to set the default builtin font
>>(`userfont == 0`), the restoration is completely skipped.
>>
>>This causes a state machine corruption where `p->userfont` remains `0`
>>while `p->fontdata` still points to the previously allocated user font
>>memory. Later, when the console is destroyed (e.g., via VT_DISALLOCATE),
>>fbcon_free_font() fails to free this memory because its `if (p->userfont)`
>>check fails, resulting in a memory leak caught by kmemleak:
>>
>>  unreferenced object 0xffff888127ea0000 (size 33296):
>>    comm "syz.0.8726", pid 33224, jiffies 4297754643
>>    hex dump (first 32 bytes):
>>      a6 e4 f9 dd 00 00 00 00 00 82 00 00 01 00 00 00  ................
>>      d2 09 6c bf 52 8a 7d d4 ef 1d 59 16 51 86 32 bf  ..l.R.}...Y.Q.2.
>>    backtrace (crc 4a0a57dd):
>>      ___kmalloc_large_node+0xe7/0x180 mm/slub.c:5214
>>      __kmalloc_large_node_noprof+0x29/0x130 mm/slub.c:5232
>>      __do_kmalloc_node mm/slub.c:5248 [inline]
>>      __kmalloc_noprof+0x5fc/0x7c0 mm/slub.c:5272
>>      kmalloc_noprof include/linux/slab.h:954 [inline]
>>      fbcon_set_font+0x431/0xa60 drivers/video/fbdev/core/fbcon.c:2525
>>      con_font_set drivers/tty/vt/vt.c:4918 [inline]
>>      con_font_op+0x94d/0xe80 drivers/tty/vt/vt.c:4958
>>      vt_k_ioctl drivers/tty/vt/vt_ioctl.c:472 [inline]
>>      vt_ioctl+0x63c/0x2ee0 drivers/tty/vt/vt_ioctl.c:743
>>
>>Fix this by moving the `p->userfont = old_userfont` assignment outside
>>the `if (userfont)` block so that the terminal state is unconditionally
>>and correctly restored regardless of which font setting triggered the
>>error.
>>
>>Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed")
>>Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>>---
>> drivers/video/fbdev/core/fbcon.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>>diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>>index 666261ae59d8..a38545dc8416 100644
>>--- a/drivers/video/fbdev/core/fbcon.c
>>+++ b/drivers/video/fbdev/core/fbcon.c
>>@@ -2461,8 +2461,10 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
>> 	p->fontdata = old_data;
>> 	vc->vc_font.data = old_data;
>> 
>>+	/* Unconditionally restore the previous userfont state */
>>+	p->userfont = old_userfont;
>>+
>> 	if (userfont) {
>>-		p->userfont = old_userfont;
>> 		if (--REFCOUNT(data) == 0)
>> 			kfree(data - FONT_EXTRA_WORDS * sizeof(int));
>> 	}
>>-- 
>>2.34.1

Re: Re:[PATCH 7.0] fbdev: fbcon: fix memory leak in error path of fbcon_do_set_font()

[Greg KH]

On Mon, Jul 27, 2026 at 03:00:34PM +0800, w15303746062 wrote:
> 
> From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
> 
> Hi Helge, Simona, and all,
> 
> Resending this patch as a gentle reminder, since it has been a while 
> from the original submission (May 25) and my previous ping (June 5).
> 
> As a quick note, since this memory leak was implicitly resolved in 
> mainline via a recent refactor, this fix is specifically targeted at 
> 7.0 and older stable branches using the legacy userfont logic.

Why not just take the same upstream commits for older kernels as well?

Whenever you do "one off" patches like this, it makes backporting future
changes/fixes almost impossible, and we almost always get it wrong.  So
backporting the same changes is almost always the best idea.

Also note that the 7.0.y kernel is long end-of-life.

thanks,

greg k-h

Re:Re: Re:[PATCH 7.0] fbdev: fbcon: fix memory leak in error path of fbcon_do_set_font()

[w15303746062]

>
>Why not just take the same upstream commits for older kernels as well?
>
>Whenever you do "one off" patches like this, it makes backporting future
>changes/fixes almost impossible, and we almost always get it wrong.  So
>backporting the same changes is almost always the best idea.
>
>Also note that the 7.0.y kernel is long end-of-life.
>

From: Mingyu Wang <25181214217@stu.xidian.edu.cn>

Hi Greg,

Understood. Thanks for the explanation and for letting me know.

I will drop this patch since 7.0 is EOL, and I will make sure 
to stick to upstream commits for future backports.

Best regards,
Mingyu