linux-kernel - Re: [PATCH] Fix blktrace setup 32-bit ioctl on 64-bit kernels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071004181606.GH5711@kernel.dk>
Date:	Thu, 4 Oct 2007 20:16:06 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-kernel@...r.kernel.org, davem@...emloft.net, hch@....de,
	Al Viro <viro@....linux.org.uk>
Subject: Re: [PATCH] Fix blktrace setup 32-bit ioctl on 64-bit kernels

On Thu, Oct 04 2007, Arnd Bergmann wrote:
> On Wednesday 03 October 2007, Arnd Bergmann wrote:
> > Jens, I think the best overall solution would be to have a
> > block/compat_ioctl.c file with all the compat handling for block
> > devices moved over from fs/compat_ioctl.c, and done in a nicer way.
> > If you agree, with this approach, I'd volunteer to come up with a
> > patch.
> 
> Sometimes I find it hard to stop myself once I have the idea.
> The patch below moves all block related ioctl conversion out
> of fs/compat_ioctl.c into the compat_blkdev_ioctl() function.
> 
> Is that a direction we should be heading towards? If so, I
> can do some testing and split this big patch into more
> logical units for better review.

This looks a lot better! I don't mind seperating the block bits, when we
get the whole bunch in there. Just seemed overly silly and complicated
to do it for just one ioctl command. When you are happy with this patch,
I'll add it to the pending block stuff for 2.6.24. The blktrace fix
isn't a regression so need not go into 2.6.23.

It seems some bits are missing though (like BLKTRACESETUP32), did you
send the whole thing?

> I also found a few interesting bugs in the process:
> * BLKRASET is both ULONG_IOCTL and COMPATIBLE_IOCTL, but this should
>   be entirely harmless
> * BLKSECTGET writes 2 bytes normally, our compat_ version writes
>   4 bytes!
> * FDSETPRM32, FDDEFPRM32 and FDGETPRM32 are doing potentially dangerous
>   stuff with kernel pointers. sparse actually warns about this, but
>   from what I could see from floppy.c, the kernel always ignores these
>   pointers. I did not check any other floppy drivers implementing the
>   same calls.

Always nice to find bugs when doing cleanups ;-)


-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/