Re: [PATCH v2 1/1] x86/vm86: fix vm86 struct leak on copy_from_user() failure

[Brian Gerst]

On Wed, Jun 24, 2026 at 10:30 PM <fffsqian@xxxxxxx> wrote:
>
> From: Qingshuang Fu <fuqingshuang@xxxxxxxxxx>
>
> When copy_from_user() fails during vm86 setup in do_sys_vm86(),
> the newly allocated vm86 structure is not freed, leading to a
> memory leak that can be exploited by users with appropriate
> privileges to cause DoS through resource exhaustion.
>
> The leak occurs in multiple error paths after kzalloc_obj()
> successfully allocates the vm86 structure and assigns it to
> tsk->thread.vm86. Subsequent copy_from_user() failures for
> vm86_struct, int_revectored, int21_revectored, or vm86plus data
> leave the allocated memory orphaned.
>
> Fix this by saving the original vm86 pointer before allocation.
> On error cleanup, if a new vm86 was allocated this call, restore
> the original pointer and free the new allocation.
>
> Security impact: This memory leak can lead to system DoS via OOM if
> exploited by unprivileged local users, provided the system has
> mmap_min_addr set to 0. The regression was introduced in commit
> 9fda6a0681e0 ("x86/vm86: Move vm86 fields out of 'thread_struct'") back
> in 2015, and affects all 32-bit x86 kernels built with CONFIG_VM86
> enabled.

I don't think you understand what the code is doing here.  The memory
is allocated once on the first call to sys_vm86().  That saves memory
for the vast majority of tasks that do not use vm86 mode.  The memory
is then freed when the task terminates.

There is no "leak" in the usual sense that the pointer is lost.  The
only real potential issue here is that memory gets allocated on a call
that does not succeed. But it is not an unbounded allocation, since it
is only once per task.