From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: soufianeda@tutanota.com
Cc: Linux Media <linux-media@vger.kernel.org>,
Linux Staging <linux-staging@lists.linux.dev>,
Gregkh <gregkh@linuxfoundation.org>,
Johannes Goede <johannes.goede@oss.qualcomm.com>,
Andy <andy@kernel.org>, Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: [PATCH] staging: atomisp: fix heap buffer overflow in framebuffer conversion
Date: Sat, 28 Feb 2026 01:58:58 +0200 [thread overview]
Message-ID: <aaIvwnCTMkPcfBS2@kekkonen.localdomain> (raw)
In-Reply-To: <OlBwH9n--F-9@tutanota.com>
Hi Soufiane,
On Wed, Feb 11, 2026 at 02:43:17PM +0100, soufianeda@tutanota.com wrote:
>
> Hi Sakari,
>
> I agree that removing the private IOCTL handler is the better
> approach. While fuzzing the driver I found the same class of
> unchecked user-controlled size fields in several other handlers
> (ATOMISP_IOC_S_DIS_VECTOR, morph table, shading table), so
> removing atomisp_vidioc_default() eliminates all of them at once.
>
> I'm cool with sending a patch removing atomisp_vidioc_default() as
> Hans suggested, if that would be helpful.
Oops. I read your message after posting the patch...
Indeed it sounds like we should disable all private IOCTLs, also the only
one that should have been there to begin with. (I can update my patch as
well.)
--
Kind regards,
Sakari Ailus
next prev parent reply other threads:[~2026-02-27 23:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260210-atomisp-fix-v1-1-024429cbff31@tutanota.com>
[not found] ` <aYt-vrc7h7CJOmSu@stanley.mountain>
2026-02-11 8:11 ` [PATCH] staging: atomisp: fix heap buffer overflow in framebuffer conversion Sakari Ailus
2026-02-11 8:59 ` Andy Shevchenko
2026-02-11 11:28 ` johannes.goede
2026-02-11 11:39 ` Andy Shevchenko
2026-02-11 11:50 ` johannes.goede
2026-02-11 11:54 ` Sakari Ailus
2026-02-11 12:31 ` johannes.goede
2026-02-11 13:27 ` Andy Shevchenko
2026-02-11 13:43 ` soufianeda
2026-02-27 23:58 ` Sakari Ailus [this message]
[not found] ` <Ol83sWa--F-9@tutanota.com>
[not found] ` <aYwVNjC7Zbhr_4vo@stanley.mountain>
2026-02-11 13:37 ` soufianeda
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=aaIvwnCTMkPcfBS2@kekkonen.localdomain \
--to=sakari.ailus@linux.intel.com \
--cc=andy@kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=johannes.goede@oss.qualcomm.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=soufianeda@tutanota.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