linux-kernel - Re: CVE-2022-50390: drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20251229162138-7ad9c5d1f5962cd8cb82c229-pchelkin@ispras>
Date: Mon, 29 Dec 2025 16:49:38 +0300
From: Fedor Pchelkin <pchelkin@...ras.ru>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, cve@...nel.org
Cc: linux-cve-announce@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Gaosheng Cui <cuigaosheng1@...wei.com>, Christian König <christian.koenig@....com>
Subject: Re: CVE-2022-50390: drm/ttm: fix undefined behavior in bit shift for
 TTM_TT_FLAG_PRIV_POPULATED

Greg Kroah-Hartman <gregkh@...nel.org> wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED
> 
> Shifting signed 32-bit value by 31 bits is undefined, so changing
> significant bit to unsigned. The UBSAN warning calltrace like below:
> 
> UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26
> left shift of 1 by 31 places cannot be represented in type 'int'
> Call Trace:
>  <TASK>
>  dump_stack_lvl+0x7d/0xa5
>  dump_stack+0x15/0x1b
>  ubsan_epilogue+0xe/0x4e
>  __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
>  ttm_bo_move_memcpy+0x3b4/0x460 [ttm]
>  bo_driver_move+0x32/0x40 [drm_vram_helper]
>  ttm_bo_handle_move_mem+0x118/0x200 [ttm]
>  ttm_bo_validate+0xfa/0x220 [ttm]
>  drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper]
>  drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper]
>  drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper]
>  drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper]
>  drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper]
>  drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper]
>  drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper]
>  drm_atomic_commit+0x9c/0x160 [drm]
>  drm_client_modeset_commit_atomic+0x33a/0x380 [drm]
>  drm_client_modeset_commit_locked+0x77/0x220 [drm]
>  drm_client_modeset_commit+0x31/0x60 [drm]
>  __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper]
>  drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper]
>  fbcon_init+0x316/0x790
>  visual_init+0x113/0x1d0
>  do_bind_con_driver+0x2a3/0x5c0
>  do_take_over_console+0xa9/0x270
>  do_fbcon_takeover+0xa1/0x170
>  do_fb_registered+0x2a8/0x340
>  fbcon_fb_registered+0x47/0xe0
>  register_framebuffer+0x294/0x4a0
>  __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper]
>  drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper]
>  drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper]
>  drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper]
>  bochs_pci_probe+0x6ca/0x772 [bochs]
>  local_pci_probe+0x4d/0xb0
>  pci_device_probe+0x119/0x320
>  really_probe+0x181/0x550
>  __driver_probe_device+0xc6/0x220
>  driver_probe_device+0x32/0x100
>  __driver_attach+0x195/0x200
>  bus_for_each_dev+0xbb/0x120
>  driver_attach+0x27/0x30
>  bus_add_driver+0x22e/0x2f0
>  driver_register+0xa9/0x190
>  __pci_register_driver+0x90/0xa0
>  bochs_pci_driver_init+0x52/0x1000 [bochs]
>  do_one_initcall+0x76/0x430
>  do_init_module+0x61/0x28a
>  load_module+0x1f82/0x2e50
>  __do_sys_finit_module+0xf8/0x190
>  __x64_sys_finit_module+0x23/0x30
>  do_syscall_64+0x58/0x80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
>  </TASK>
> 
> The Linux kernel CVE team has assigned CVE-2022-50390 to this issue.

Hi,

I would like to dispute this CVE.  Shifting signed 32-bit value by 31 bits
is not considered as undefined behavior in the kernel since it is compiled
with -fno-strict-overflow flag which implies -fwrapv.  There are still
_lots_ of (1 << 31) cases in the kernel.  If there were real problems,
they'd be hit everywhere.

Presence of UBSAN splat in the changelog is rather interesting.  Commit
f1887143f598 ("Documentation/atomic_t: Clarify signed vs unsigned") states:

   the kernel uses -fno-strict-overflow
   (which implies -fwrapv) and defines signed overflow to behave like
   2s-complement.

   Therefore, an explicitly unsigned variant of the atomic ops is strictly
   unnecessary and we can simply cast, there is no UB.

   There was a bug in UBSAN prior to GCC-8 that would generate UB warnings for
   signed types.

so it looks like those UBSAN splats were caught due to an old compiler's
problem, not the kernel's.

That said, the result of (1 << 31) is 0x80000000, it has the signed bit
set to 1 so if it's later used in arithmetic with bigger (64-bit) types,
there'd be a signed extension to 0xffffffff80000000 that may be unexpected
in some circumstances.

The current CVE doesn't concern the potentially unexpected signed
extension either.  TTM_TT_FLAG_PRIV_POPULATED is only ever used for
bitwise operations with 32-bit integer 'flags'.

--
Fedor