[Bug 38639] CDex v1.78 crashes when leaving 'options' menu with 'ok' without media inserted

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=38639

Anastasius Focht <focht at 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 at 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

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.