Linux kernel staging patches
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Murad Sadigov <sdgvmrd@gmail.com>
Cc: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: axis-fifo: fix integer overflow in write()
Date: Tue, 7 Oct 2025 15:01:22 +0200	[thread overview]
Message-ID: <2025100729-voltage-boondocks-d8da@gregkh> (raw)
In-Reply-To: <2025100757-proximity-unlighted-6ad4@gregkh>

On Tue, Oct 07, 2025 at 02:18:47PM +0200, Greg KH wrote:
> On Tue, Oct 07, 2025 at 03:58:13PM +0400, Murad Sadigov wrote:
> > Fix integer overflow in axis_fifo_write() that allows local users
> > to bypass buffer validation, potentially causing hardware FIFO
> > buffer overflow and system denial of service.
> > 
> > The axis_fifo_write() function converts user-controlled size_t 'len'
> > (64-bit) to unsigned int 'words_to_write' (32-bit) without overflow
> > checking at line 322:
> > 
> >     words_to_write = len / sizeof(u32);
> > 
> > On 64-bit systems, when len equals 0x400000000 (16 GiB):
> >   - Division: 0x400000000 / 4 = 0x100000000 (requires 33 bits)
> >   - Truncation: Result stored in 32-bit variable = 0 (overflow)
> >   - Validation bypass: if (0 > fifo_depth) evaluates to false
> >   - Impact: Hardware FIFO overflow, system crash
> > 
> > This allows unprivileged local users with access to /dev/axis_fifo*
> > to trigger denial of service.
> > 
> > The fix adds overflow check before type conversion to ensure len
> > does not exceed the maximum safe value (UINT_MAX * sizeof(u32)).
> > 
> > Affected systems include embedded devices using Xilinx FPGA with
> > AXI-Stream FIFO IP cores.
> > 
> > Signed-off-by: Murad Sadigov <sdgvmrd@gmail.com>
> > ---
> >  drivers/staging/axis-fifo/axis-fifo.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/staging/axis-fifo/axis-fifo.c
> > b/drivers/staging/axis-fifo/axis-fifo.c
> > index 1234567890ab..abcdef123456 100644
> > --- a/drivers/staging/axis-fifo/axis-fifo.c
> > +++ b/drivers/staging/axis-fifo/axis-fifo.c
> > @@ -319,6 +319,13 @@ static ssize_t axis_fifo_write(struct file *f,
> > const char __user *buf,
> >   return -EINVAL;
> >   }
> > 
> > + /* Prevent integer overflow in words calculation */
> > + if (len > (size_t)UINT_MAX * sizeof(u32)) {
> > + dev_err(fifo->dt_device,
> > + "write length %zu exceeds maximum %zu bytes\n",
> > + len, (size_t)UINT_MAX * sizeof(u32));
> > + return -EINVAL;
> > + }
> > +
> 
> Something went wrong here, your email client dropped all of the leading
> spaces :(
> 
> Also, you do not want to allow userspace to cause a DoS on the kernel
> log, so don't log this information, just return an error, no need to
> print anything.

Also, look at this function in the linux-next branch.  It has been
rewritten and I think will not fail in the same way you are thinking it
will fail here.  I'll get those changes to Linus by the end of this
week, sorry for not noticing they were not flushed out to his tree yet.

thanks,

greg k-h

  reply	other threads:[~2025-10-07 13:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-07 11:58 [PATCH] staging: axis-fifo: fix integer overflow in write() Murad Sadigov
2025-10-07 12:18 ` Greg KH
2025-10-07 13:01   ` Greg KH [this message]
2025-10-07 13:05 ` Dan Carpenter

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=2025100729-voltage-boondocks-d8da@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=sdgvmrd@gmail.com \
    /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