linux-kernel - Re: "Fix ATAPI transfer lengths" causes CD writing regression

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: <47276DCA.1000808@gentoo.org>
Date:	Tue, 30 Oct 2007 17:45:46 +0000
From:	Daniel Drake <dsd@...too.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	linux list <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org
Subject: Re: "Fix ATAPI transfer lengths" causes CD writing regression

Alan Cox wrote:
> Not immediately - but if you've got wrong transfer lengths its a
> candidate for this.
> 
> Ok lets start with the basics
> 
> If you mount a CD and use it does it work

Yep.

> If you use cdrecord does it work ?

Yep (tested with wodim from debburn, effectively the same thing)

> What vendor drive and does it seem to be a specific box/drive that
> triggers this ?

Device type    : Removable CD-ROM
Version        : 5
Response Format: 2
Capabilities   :
Vendor_info    : 'PHILIPS '
Identification : 'DVD+-RW SDVD8820'
Revision       : 'AD15'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R

This is on my laptop (Dell Inspiron 640m). I won't have access to 
another system to test this there until next week.

The nutty app I was using for burning is Brasero, a GNOME app which does 
some SG_IO directly with the drive. (I guess it has some bad error 
handling and doesn't realise when some I/O path has failed)

I have narrowed down the exact command submission which causes those 
nasty messages in dmesg. The function which submits this is named 
"brasero_medium_get_page_2A_write_speed_desc".

The test program that I've attached can now reproduce this error every 
time it is run. The output is:

	result 0
	check sense data:
	72 0b 47 00 00 00 00 0e 09 0c 00 00 00 02 00 00 00 0a 00

I get the same output and dmesg errors even when there is no media in 
the drive.

I have had a quick look at the SCSI command being submitted there, and 
don't see anything wrong.

What next?

Daniel

View attachment "testsg.c" of type "text/plain" (1472 bytes)