All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	 stable <stable@kernel.org>
Subject: Re: [PATCH 2/2] Input: synaptics-rmi4 - use u32 for reg_size to avoid sign extension into item->reg_size
Date: Wed, 22 Apr 2026 18:59:31 -0700	[thread overview]
Message-ID: <ael3yDbI3_1oarHN@google.com> (raw)
In-Reply-To: <2026042046-clad-aspect-e8f9@gregkh>

On Mon, Apr 20, 2026 at 08:59:46PM +0200, Greg Kroah-Hartman wrote:
> rmi_read_register_desc() builds the 4-byte register size from device
> bytes:
> 
> 	reg_size = struct_buf[offset] |
> 		   (struct_buf[offset + 1] << 8) |
> 		   (struct_buf[offset + 2] << 16) |
> 		   (struct_buf[offset + 3] << 24);
> 
> struct_buf is u8 *, so each byte is promoted to int before the shift.  A
> device that supplies a top byte with bit 7 set (e.g. 00 00 00 00 00 00
> 80 in struct_buf to reach the 4-byte path with offset+3 = 0x80) makes
> (0x80 << 24) overflow into the int sign bit, and the OR result is
> negative.  reg_size is then assigned to item->reg_size, which is
> unsigned long, so the negative int sign-extends to a value near
> ULONG_MAX.
> 
> After this, bad things happen when numbers start wrapping and buffers
> are allocatged based on those numbers, and then accessed based on those
> buffers assuming to be a sane size (bigger or smaller).
> 
> Fix this all up by just properly making reg_size be a u32.

Shouldn't it be replaced with get_unaligned_le32() instead?

Thanks.

-- 
Dmitry

  reply	other threads:[~2026-04-23  1:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-20 18:59 [PATCH 1/2] Input: synaptics-rmi4 - validate register descriptor structure against its declared size Greg Kroah-Hartman
2026-04-20 18:59 ` [PATCH 2/2] Input: synaptics-rmi4 - use u32 for reg_size to avoid sign extension into item->reg_size Greg Kroah-Hartman
2026-04-23  1:59   ` Dmitry Torokhov [this message]
2026-04-23  4:50     ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ael3yDbI3_1oarHN@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.