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
