All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@saeurebad.de>
To: Dave Airlie <airlied@redhat.com>
Cc: Sitsofe Wheeler <sitsofe@yahoo.com>, linux-kernel@vger.kernel.org
Subject: Re: BUG: unable to handle kernel NULL pointer dereference (drm_getunique)
Date: Thu, 05 Jun 2008 20:04:50 +0200	[thread overview]
Message-ID: <87ve0n69ml.fsf@saeurebad.de> (raw)
In-Reply-To: <1212635129.24094.11.camel@clockmaker.usersys.redhat.com> (Dave Airlie's message of "Thu, 05 Jun 2008 13:05:29 +1000")

Hi,

Dave Airlie <airlied@redhat.com> writes:

>> Make that run-time tested, also.  This does not just affect linux-next.
>> The following program oopses my box running Linus' current git:
>> 
>> #include <fcntl.h>
>> #include <unistd.h>
>> #include <sys/ioctl.h>
>> 
>> #include <drm/drm.h>
>> 
>> #define DRM_DFILE		"/dev/dri/card0"
>> #define DRM_IOCTL_CAPUT		_IO(DRM_IOCTL_BASE, 0x01)
>> 
>> int main(void)
>> {
>> 	int fd = open(DRM_DFILE, O_RDONLY);
>> 
>> 	if (fd < 0)
>> 		return 1;
>> 
>> 	ioctl(fd, DRM_IOCTL_CAPUT);
>> 	perror("ioctl");
>> 	close(fd);
>> 	return 0;
>> }
>> 
>> ->
>> 
>> [  714.581505] BUG: unable to handle kernel NULL pointer dereference at 00000000
>> [  714.583459] IP: [<c027d491>] drm_getunique+0x11/0x40
>> [  714.585460] *pde = 00000000 
>> [  714.587389] Oops: 0000 [#1] PREEMPT 
>> [  714.588271] Modules linked in: snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_page_alloc
>> [  714.588271] 
>> [  714.588271] Pid: 1339, comm: break-drm Not tainted (2.6.26-rc4-00232-gedeb280 #43)
>> [  714.588271] EIP: 0060:[<c027d491>] EFLAGS: 00010282 CPU: 0
>> [  714.588271] EIP is at drm_getunique+0x11/0x40
>> [  714.588271] EAX: cf861000 EBX: 00000000 ECX: 00000000 EDX: 00000000
>> [  714.588271] ESI: cf861000 EDI: cfa87700 EBP: 00000000 ESP: cecc3f20
>> [  714.588271]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
>> [  714.588271] Process break-drm (pid: 1339, ti=cecc2000 task=cf9a6dc0 task.ti=cecc2000)
>> [  714.588271] Stack: c027d480 cf861000 c027c592 ced53b7c b7fc00d0 c0159f3b ced53b7c 000000ce 
>> [  714.588271]        00000000 00000000 00006401 00000000 cf861024 c04730a0 ced33700 bf965788 
>> [  714.588271]        00006401 c017aea8 bf965788 ced33700 ced33700 00000003 cecc2000 c017b0fb 
>> [  714.588271] Call Trace:
>> [  714.588271]  [<c027d480>] drm_getunique+0x0/0x40
>> [  714.588271]  [<c027c592>] drm_ioctl+0x1a2/0x2e0
>> [  714.588271]  [<c0159f3b>] handle_mm_fault+0xeb/0x5e0
>> [  714.588271]  [<c017aea8>] vfs_ioctl+0x78/0x90
>> [  714.588271]  [<c017b0fb>] do_vfs_ioctl+0x23b/0x2c0
>> [  714.588271]  [<c016ce2a>] do_sys_open+0xba/0xe0
>> [  714.588271]  [<c017b1bd>] sys_ioctl+0x3d/0x70
>> [  714.588271]  [<c0103152>] syscall_call+0x7/0xb
>> [  714.588271]  =======================
>> [  714.588271] Code: 8b 04 24 e8 e2 1b 12 00 31 c0 5b 5b 5e 5f 5d c3 8d 76 00 8d bc 27 00 00 00 00 83 ec 08 89 1c 24 89 d3 89 74 24 04 89 c6 8b 48 04 <39> 0a 73 11 89 0b 31 d2 8b 1c 24 89 d0 8b 74 24 04 83 c4 08 c3 
>> [  714.588271] EIP: [<c027d491>] drm_getunique+0x11/0x40 SS:ESP 0068:cecc3f20
>> [  714.659745] ---[ end trace fd8339ca8c62cb63 ]---
>> [  714.663840] [drm:drm_release] *ERROR* Device busy: 1 0
>> 
>> My patch fixes this, but here is a better one that checks the whole cmd
>> against the allowed one.  Otherwise, it would be possible to trap the
>> kernel into allocating 2^15-1 bytes through kmalloc, too, at least on
>> this configuration here with _IOC_SIZEBITS == 14.
>> 
>> ---
>> drm: sanity-check ioctl request
>> 
>> drm_ioctl looks up a dispatcher function for special ioctls but it does
>> not precheck the commands against the registered ones, allowing users to
>> pass bogus values and potentially oops the kernel, as happened to
>> Sitsofe Wheeler who reported this bug.
>> 
>> This patch checks the incoming ioctl command against the defined ones
>> before dispatching to the handler.
>> 
>
>
> This patch will break some other parts of the DRM interface, I'll try
> and come up with one that is less likely do stop all the drivers
> working.

We do not want that to happen, of course :)

> The problem is there are binaries out there with bad userspace ioctl
> bits..
>
> What I'll change it to do is at least allocate the size from the kernel
> definition not what the user passed in.
>
> The big problem we have with malformed requests is that userspace asks
> for one thing and expects another, so I should key the userspace from
> the ioctl nr and use the kernel side definitions to decide the other
> bits. Clearly the drm code isn't doing that now.

Hm, like this?

diff --git a/drivers/char/drm/drm_drv.c b/drivers/char/drm/drm_drv.c
index fc54140..019bf1f 100644
--- a/drivers/char/drm/drm_drv.c
+++ b/drivers/char/drm/drm_drv.c
@@ -475,6 +475,9 @@ int drm_ioctl(struct inode *inode, struct file *filp,
 	else
 		goto err_i1;
 
+	/* Do not trust userspace, use our own definition */
+	cmd = ioctl->cmd;
+
 	func = ioctl->func;
 	/* is there a local override? */
 	if ((nr == DRM_IOCTL_NR(DRM_IOCTL_DMA)) && dev->driver->dma_ioctl)

      reply	other threads:[~2008-06-05 18:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-04 23:03 BUG: unable to handle kernel NULL pointer dereference (drm_getunique) Sitsofe Wheeler
2008-06-04 23:42 ` Johannes Weiner
2008-06-05  7:08   ` Sitsofe Wheeler
2008-06-05  0:54 ` Johannes Weiner
2008-06-05  2:21   ` Johannes Weiner
2008-06-05  3:05     ` Dave Airlie
2008-06-05 18:04       ` Johannes Weiner [this message]

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=87ve0n69ml.fsf@saeurebad.de \
    --to=hannes@saeurebad.de \
    --cc=airlied@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sitsofe@yahoo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.