From: Matthew Wilcox <matthew@wil.cx>
To: Jeff Garzik <jeff@garzik.org>
Cc: linux-ide@vger.kernel.org
Subject: Re: [RFC] Read/Write Buffer support
Date: Sat, 15 Mar 2008 11:49:29 -0600 [thread overview]
Message-ID: <20080315174929.GY613@parisc-linux.org> (raw)
In-Reply-To: <47DC04CD.7060209@garzik.org>
On Sat, Mar 15, 2008 at 01:18:05PM -0400, Jeff Garzik wrote:
> >+ local_irq_save(flags);
> >+
> >+ buflen = ata_scsi_rbuf_get(cmd, &rbuf);
> >+
> >+ memset(rbuf, 0, buflen);
> >+ rbuf[0] = desc ? 0xff : 0x0;
> >+ rbuf[1] = 0x0;
> >+ rbuf[2] = 0x2;
> >+ rbuf[3] = 0x0;
> >+
> >+ ata_scsi_rbuf_put(cmd, rbuf);
> >+
> >+ local_irq_restore(flags);
> >+}
>
> use ata_scsi_rbuf_fill() rather than recreating it manually
ata_scsi_rbuf_fill() calls args->done(cmd). Now, I can split the common
part of ata_scsi_rbuf_fill into a different function if you'd like, but
see below.
> >+ /* XXX: fewer than 4 bytes in the page? Doomed. */
> >+ sg->offset += 4;
> >+ sg->length -= 4;
>
> I'm quite uncomfortable skipping any amount of validation.
Two things ... first, this is just a cheesy hack. I'd like (but I don't
see) a generic way to say "I've filled in the first N bytes of this
scatterlist, please adjust and continue". That's something that should
go in lib/scatterlist.c, IMO.
Second, and more seriously, libata already makes much worse assumptions
than this about scatterlists; it's just that the person who wrote them
didn't know it (or didn't flag it). Look at the simulation of an
INQUIRY, for example. It calls:
ata_scsi_rbuf_fill(&args, ata_scsiop_inq_std);
which does:
buflen = ata_scsi_rbuf_get(cmd, &rbuf);
rc = actor(args, rbuf, buflen);
ata_scsi_rbuf_get() does:
buf = kmap_atomic(sg_page(sg), KM_IRQ0) + sg->offset;
buflen = sg->length;
ata_scsiop_inq_std() (before it checks buflen) does:
memcpy(rbuf, hdr, sizeof(hdr));
So if a user can persuade the kernel to do an SG transfer directly to
userspace and sets up the address one byte before the end of the page,
they can persuade libata to write 4 bytes into the page after KM_IRQ0.
Which is probably hard to exploit in a meaningful way, but could
certainly cause crashes and/or corruption.
> Style in libata is "FIXME" or "TODO" not "XXX". Please help with
> consistency, it makes grepping easier.
Fine by me.
> Plus, I dunno about you, but I'm not a porn star :)
Matthew "Spankalicious" Wilcox.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2008-03-15 17:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-15 15:37 [RFC] Read/Write Buffer support Matthew Wilcox
2008-03-15 17:18 ` Jeff Garzik
2008-03-15 17:49 ` Matthew Wilcox [this message]
2008-03-15 22:48 ` Jeff Garzik
2008-03-15 23:09 ` Alan Cox
2008-03-16 0:46 ` Matthew Wilcox
2008-03-16 1:47 ` Jeff Garzik
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=20080315174929.GY613@parisc-linux.org \
--to=matthew@wil.cx \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).