linux-kernel - Re: [PATCH] HID: multitouch: fix integer overflow in set

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aJjXacCgSk-aNyTh@gmail.com>
Date: Sun, 10 Aug 2025 18:31:35 +0100
From: Qasim Ijaz <qasdev00@...il.com>
To: Jiri Slaby <jirislaby@...nel.org>
Cc: jikos@...nel.org, bentiss@...nel.org, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] HID: multitouch: fix integer overflow in set_abs()

On Thu, Jul 31, 2025 at 09:43:38AM +0200, Jiri Slaby wrote:
> On 24. 07. 25, 17:56, Qasim Ijaz wrote:
> > On Thu, Jul 24, 2025 at 08:58:40AM +0200, Jiri Slaby wrote:
> > > On 23. 07. 25, 19:36, Qasim Ijaz wrote:
> > > > It is possible for a malicious HID device to trigger a signed integer
> > > > overflow (undefined behaviour) in set_abs() in the following expression
> > > > by supplying bogus logical maximum and minimum values:
> > > > 	
> > > > 	int fuzz = snratio ? (fmax - fmin) / snratio : 0;
> > > > 
> > > > For example, if the logical_maximum is INT_MAX and logical_minimum is -1
> > > > then (fmax - fmin) resolves to INT_MAX + 1, which does not fit in a 32-bit
> > > > signed int, so the subtraction overflows.
> > > 
> > > The question is if it matters with -fwrapv?
> > 
> > Ah yea thanks for bringing this up Jiri. I think you might be correct,
> > after doing some research it looks like the kernel enables -fno‑strict‑overflow
> > which implies -fwrapv which leads to wrap around instead of UB If I undestand
> > correctly. So with that in mind this patch probably doesn't do anything
> > useful, do you agree?
> 
> Yes, it correctly wraps around. But the question remains :). Does it matter
> or not?
> 

probably not. From what I can tell it doesn't look like any further security
issues occur as a result of the wrap around behaviour so i think its
probably best to drop this patch.

thanks,
qasim
> thanks,
> -- 
> js
> suse labs