From: "Németh Márton" <nm127@freemail.hu>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>,
V4L Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH] libv4l: add NULL pointer check
Date: Mon, 31 Aug 2009 22:36:40 +0200 [thread overview]
Message-ID: <4A9C3458.8050304@freemail.hu> (raw)
In-Reply-To: <200908312216.14184.laurent.pinchart@ideasonboard.com>
Laurent Pinchart wrote:
> On Monday 31 August 2009 15:19:32 Mauro Carvalho Chehab wrote:
>> Em Mon, 31 Aug 2009 08:52:38 +0200
>>
>> Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
>>>> - dereferencing a NULL pointer is not always result segfault, see [1]
>>>> and [2]. So dereferencing a NULL pointer can be treated also as a
>>>> security risk.
>> From kernelspace drivers POV, any calls sending a NULL pointer should
>> result in an error as soon as possible, to avoid any security risks.
>> Currently, this check is left to the driver, but we should consider
>> implementing such control globally, at video_ioctl2 and at compat32 layer.
>>
>> IMHO, libv4l should mimic the driver behavior of returning an error instead
>> of letting the application to segfault, since, on some critical
>> applications, like video-surveillance security systems, a segfault could be
>> very bad.
>
> And uncaught errors would be even better. A segfault will be noticed right
> away, while an unhandled error code might slip through to the released
> software. If a security-sensitive application passes a NULL pointer where it
> shouldn't I'd rather see the development machine burst into flames instead of
> silently ignoring the problem.
I have an example. Let's imagine the following code:
struct v4l2_capability* cap;
cap = malloc(sizeof(*cap));
ret = ioctl(f, VIDIOC_QUERYCAP, cap);
if (ret == -1) {
/* error handling */
}
Does this code contain implementation problem? Yes, the value of cap should
be checked whether it is NULL or not.
Will this code cause problem? Most of the time not, only in case of low
memory condition, thus this implementation problem will usually not detected
if the ioctl() caused segfault on NULL pointers.
One more thing I would like to mention on this topic. This is coming from
the C language which does not contain structured exception handling as for
example Java has with its exception handling capability. The usual way to
signal errors is through the return value. This is what a C programmer learns
and this is what she or he expects. The signals as segfault is out of the
scope of the C language.
Regards,
Márton Németh
next prev parent reply other threads:[~2009-08-31 20:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-30 8:56 [PATCH] libv4l: add NULL pointer check Németh Márton
2009-08-30 21:33 ` Laurent Pinchart
2009-08-31 5:51 ` Németh Márton
2009-08-31 6:52 ` Laurent Pinchart
2009-08-31 13:19 ` Mauro Carvalho Chehab
2009-08-31 20:16 ` Laurent Pinchart
2009-08-31 20:36 ` Németh Márton [this message]
2009-09-01 8:06 ` Hans de Goede
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=4A9C3458.8050304@freemail.hu \
--to=nm127@freemail.hu \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@infradead.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