linux-kernel - Re: CVE-2022-50403: ext4: fix undefined behavior in bit shift for ext4_check_flag

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: <20251229172142-b5ad8a449d69ae636456d36d-pchelkin@ispras>
Date: Mon, 29 Dec 2025 17:28:43 +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>, Theodore Ts'o <tytso@....edu>
Subject: Re: CVE-2022-50403: ext4: fix undefined behavior in bit shift for
 ext4_check_flag_values

Greg Kroah-Hartman <gregkh@...nel.org> wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> ext4: fix undefined behavior in bit shift for ext4_check_flag_values
> 
> 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 fs/ext4/ext4.h:591:2
> 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
>  ext4_init_fs+0x5a/0x277
>  do_one_initcall+0x76/0x430
>  kernel_init_freeable+0x3b3/0x422
>  kernel_init+0x24/0x1e0
>  ret_from_fork+0x1f/0x30
>  </TASK>
> 
> The Linux kernel CVE team has assigned CVE-2022-50403 to this issue.

Hi,

I'd 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.

The current CVE doesn't concern the potentially unexpected sign-extension
either.  ext4 inode i_flags values are represented as 32-bit integers and
result of (1 << 31) is used for comparison with one of those integers.

Similar to CVE-2022-50390, the observed UBSAN splats should be due to a
UBSAN's problem, per commit f1887143f598 ("Documentation/atomic_t: Clarify
signed vs unsigned"):

   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.

--
Fedor