linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Omer Shalev <omerdeshalev@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	Richard Fontana <rfontana@redhat.com>,
	Allison Randal <allison@lohutok.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media:usb:cpia2: Properly check framebuffer mmap offsets
Date: Mon, 11 Nov 2019 18:24:42 +0000	[thread overview]
Message-ID: <20191111182409.GA20121@arch-vook> (raw)
In-Reply-To: <20191111114615.GA418224@kroah.com>

On Mon, Nov 11, 2019 at 12:46:15PM +0100, Greg Kroah-Hartman wrote:
> On Sat, Nov 09, 2019 at 12:39:43PM +0100, Hans Verkuil wrote:
> > Hi Greg,
> > 
> > On 11/8/19 9:49 PM, Greg Kroah-Hartman wrote:
> > > On Fri, Nov 08, 2019 at 09:50:36PM +0000, Omer Shalev wrote:
> > >> The cpai2 driver's mmap implementation wasn't properly check for all
> > >> possible offset values. Given a huge offset value , the calculation
> > >> start_offset + size can wrap around to a low value and pass the check
> > > 
> > > I thought we checked that in the core of the kernel now, to keep all
> > > drivers from not having to do this type of thing (as they obviously all
> > > forgot to.)  Why is this still needed here as well?
> > 
> > Where is that checked in the core? I couldn't find anything, but I might
> > have been looking in the wrong place.
> 
> Sorry, took me a while to find it.  Look at be83bbf80682 ("mmap:
> introduce sane default mmap limits") as I think this should handle the
> problem already.
> 
> thanks,
> 
> greg k-h

Thanks Greg. But All other drivers I've seen implement it like that: if(size > total_size || offset >
total_size - size). Which I think, is a better way to write this code, and generally more
secure. Plus, no extra code is needed (just changing this line).

Please let me know what you think.

Best regards,

Omer

  reply	other threads:[~2019-11-11 16:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08 21:50 [PATCH] media:usb:cpia2: Properly check framebuffer mmap offsets Omer Shalev
2019-11-08 20:49 ` Greg Kroah-Hartman
2019-11-09 11:39   ` Hans Verkuil
2019-11-11 11:46     ` Greg Kroah-Hartman
2019-11-11 18:24       ` Omer Shalev [this message]
2019-11-11 16:29         ` Greg Kroah-Hartman
2019-11-11 18:53           ` Omer Shalev

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=20191111182409.GA20121@arch-vook \
    --to=omerdeshalev@gmail.com \
    --cc=allison@lohutok.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=hverkuil@xs4all.nl \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=rfontana@redhat.com \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).