https://bugs.winehq.org/show_bug.cgi?id=38639
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Summary|CDex v1.78 crashes on |CDex v1.78 crashes when |startup |leaving 'options' menu with | |'ok' without media inserted Ever confirmed|0 |1
--- Comment #6 from Anastasius Focht focht@gmx.net --- Hello folks,
the information how to exactly reproduce the crash should have been present in first place.
The crash without CD in options menu is likely due to broken app code.
The app issues SCSI_READ_TOC via ASPI layer and ignores any returned SCSI target status (error) under assumption of a previous condition being valid.
To avoid reading the TOC on non-present media, the app issues 'TEST UNIT READY' SCSI command which returns an error as positive value (byte).
ha_stat=0 target_stat=2 sense flags 0x2,0x3A,0x02 ASPI command status 0x4
It looks like the app tries to re-interpret (cast?) the return value as boolean which causes success ("ready" = "media inserted"?) evaluation even in error cases (positive values).
Back to TOC read ... since the SCSI reply buffer was still filled with partially valid data (except for number of tracks), the app calculates the wrong number of maximum tracks from that buffer data. This leads to an out-of-bounds access of some track data structures/records? which seem to be stored as array, causing the actual page fault. It looks like the app has some hard-coded limit of 100 (0x64) tracks.
The returned buffer contents of SCSI_READ_TOC without media inserted in my case:
--- snip --- $ ==> 0033D034 32058005 $+4 0033D038 0000005B $+8 0033D03C 6D696C53 Slim $+C 0033D040 65707974 type $+10 0033D044 20204442 BD $+14 0033D048 44202045 E D $+18 0033D04C 5445344C L4ET $+1C 0033D050 20202053 S $+20 0033D054 31424151 QAB1 $+24 0033D058 30313032 2010 $+28 0033D05C 2D34302D -04- $+2C 0033D060 31203930 09 1 $+30 0033D064 34353A34 4:54 $+34 0033D068 20202020 $+38 0033D06C 00000000 .... $+3C 0033D070 00000000 .... $+40 0033D074 00000000 .... ... --- snip ---
tracks = ((sg_buffer[0] << 8) + sg_buffer[1] - 2) / 8
buf[0] = 0x05 << 8 = 0x500 buf[1] = 0x80 - 2 = 0x7E -> 0x57E >> 3 (/8) = 0xAF
One solution could be to sanitize/zero out the app provided reply buffer upon failure but I tend to say not to touch the buffer contents as returned from the device in any case.
For the second crash with media inserted I don't feel inclined to track that one down now as long as I can't reproduce it.
Also it's one problem per bug report.
Regards