linux-kernel - Re: [PATCH 01/14] ide-tape: fix potential fs requests bug

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: <20090509085008.GA5261@liondog.tnic>
Date:	Sat, 9 May 2009 10:50:08 +0200
From:	Borislav Petkov <petkovbb@...glemail.com>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Borislav Petkov <petkovbb@...glemail.com>, bzolnier@...il.com,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/14] ide-tape: fix potential fs requests bug

On Sat, May 09, 2009 at 10:02:45AM +0200, Sam Ravnborg wrote:
> On Sat, May 09, 2009 at 09:45:21AM +0200, Borislav Petkov wrote:
> > ide-tape had a potential bug for fs requests when preparing the command
> > packet: it was writing the transfer length as a number of fixed blocks.
> > However, the block layer implies 512 byte blocks and ide-tape can have
> > other block sizes so account for that too.
> > 
> > ide-floppy does this calculation properly with the block size factor
> > (floppy->bs_factor).
> > 
> > Signed-off-by: Borislav Petkov <petkovbb@...il.com>
> > ---
> >  drivers/ide/ide-tape.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
> > index e166045..fc79cf4 100644
> > --- a/drivers/ide/ide-tape.c
> > +++ b/drivers/ide/ide-tape.c
> > @@ -586,7 +586,7 @@ static void ide_tape_create_rw_cmd(idetape_tape_t *tape,
> >  				   struct ide_atapi_pc *pc, struct request *rq,
> >  				   u8 opcode)
> >  {
> > -	unsigned int length = blk_rq_sectors(rq);
> > +	unsigned int length = blk_rq_sectors(rq) / (tape->blk_size >> 9);
> 
> If tape->blk_size equals 256 or less then we get a divide-by-zero.

Yes, there is a far-fetched, potential possibility for that but here's
what the QIC 157D (http://www.qic.org/html/standards/15x.x/qic157d.pdf)
spec for streaming tapes says on block sizes:

"The Block Length specifies the current length in bytes of each logical
block described by the block descriptor for the current medium. For QIC
Streaming Tape Devices, two block sizes supported may be of either 512
or 1024 bytes per block."

Also, the driver catches invalid block sizes in
idetape_get_mode_sense_results() so I guess we should be fine.

Thanks.

-- 
Regards/Gruss,
    Boris.
--
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/