public inbox for linux-kernel@vger.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] Input: ims-pcu - bound frame parser write index against read_buf size
Date: Thu, 23 Apr 2026 10:24:08 -0700	[thread overview]
Message-ID: <aepUPTvakExa3OZS@google.com> (raw)
In-Reply-To: <2026042322-swooned-bauble-40eb@gregkh>

On Thu, Apr 23, 2026 at 06:52:23AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 22, 2026 at 06:36:24PM -0700, Dmitry Torokhov wrote:
> > Hi Greg,
> > 
> > On Mon, Apr 20, 2026 at 09:05:31PM +0200, Greg Kroah-Hartman wrote:
> > > ims_pcu_process_data() implements a STX/DLE/ETX byte-stuffing parser
> > > that accumulates frame payload into pcu->read_buf[] using the running
> > > index pcu->read_pos.  read_buf is IMS_PCU_BUF_SIZE (128) bytes and
> > > read_pos is u8 but of course, we don't check the index before actually
> > > writing the data :(
> > > 
> > > Fix this up by properly rejecting the frame at the first attempt to
> > > write past read_buf and resync on the next STX, mirroring how the parser
> > > handles short and bad-checksum frames on ETX.
> > > 
> > > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver")
> > > Cc: stable <stable@kernel.org>
> > > Assisted-by: gkh_clanker_t1000
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > I already have a patch for this, thanks.
> 
> Ah, missed that, sorry, I was working against Linus's tree.  I am
> guessing you are referring to commit 875115b82c29 ("Input: ims-pcu - fix
> heap-buffer-overflow in ims_pcu_process_data()")?  If so, why wasn't
> that tagged for stable inclusion?

I do not believe it is worth it. The driver is for specialized hardware,
so common distros will not be enabling it, and systems where it is used
likely do not allow plugging weird stuff into them and probably do not
use stable either.

I actually wonder if we need to carry the driver or if we should simply
drop it. The only non-cleanup change to it was done in 2014.

Thanks.

-- 
Dmitry

  reply	other threads:[~2026-04-23 17:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-20 19:05 [PATCH] Input: ims-pcu - bound frame parser write index against read_buf size Greg Kroah-Hartman
2026-04-23  1:36 ` Dmitry Torokhov
2026-04-23  4:52   ` Greg Kroah-Hartman
2026-04-23 17:24     ` Dmitry Torokhov [this message]
2026-04-24  4:16       ` 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=aepUPTvakExa3OZS@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox