[k3b] [Bug 382941] Segfault from getSupportedWriteSpeedsVia2A

[Thomas Schmitt]

https://bugs.kde.org/show_bug.cgi?id=382941

--- Comment #19 from Thomas Schmitt <scdbackup at gmx.net> ---
Hi,

i was not really in patch mood yet, but still in the stage of making up
theories.

Nevertheless, the new commit should really fix the problem.

Mark reports in
  https://bugs.kde.org/show_bug.cgi?id=382941#c8
that he gets data.size() == 34. Minus 8 header bytes this is mode page
length 26. This means 6 mandatory bytes from MMC-3 table 361 are missing.

In MMC-1 table 103 the mode page 2Ah is only 22 bytes long.
MMC-2 table 137 has indeed 26 bytes. It obsoletes half of the MMC-1
definition. E.g. "Maximum Write Speed Supported" and "Current Write Speed
Selected" at bytes 18 to 21.
MMC-3 then adds again a field "Current Write Speed Selected" at byte
offset 28 and the list of speed descriptors.

So yes, with page length 26 and the wrong "if" condition, K3B picked
two bytes as numDesc by
   unsigned int numDesc = from2Byte( mm->num_wr_speed_des );
which were not read from the reply of command MODE SENSE.

It did not throw any error towards Mark when it was doing this.
The error happened later when numDesc was the rolled-over unsigned
representation of the negative number and caused a long and rampant
loop until segfault by a large index "i".

---------------------------------------------------------------------

But i still riddle about the original cause to make the problematic
computation.

It is not easy to imagine how a K3B developer could have mistaken the
random number for a byte count and compute the descriptor count from
the reply size without noticing that it becomes negative and then
a very large unsigned int.

So maybe this gesture is not a reaction to MMC-1 or MMC-2 compliant replies
but rather a reaction to some other unexpected situation.

I still doubt that any drive would really announce a byte count of the
descriptor list rather than the item count of that list.
But given my current assessment, i cannot recommed to remove this
fallback computation. (I would like to. Really.)


Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are the assignee for the bug.