Unknown Feature in Discovery 0 response 0 - Segmentation fault

[Defozo]

sedutil-cli --scan results in:

Scanning for Opal compliant disks
/dev/sda  No  HGST HTS721010A9E630 ...
/dev/sdb  12  Samsung SSD 850 EVO mSATA 1TB ...
Segmentation fault

linuxpba results in:

...
- 15:53:18.620 DBG : Unknown Feature in Discovery 0 response 0
Segmentation fault

Executing sedutil-cli.exe --scan under Windows have desired results:

C:\downloads\sedutil_WIN\x64\Release>sedutil-cli.exe --scan

Scanning for Opal compliant disks
\\.\PhysicalDrive0 No  HGST HTS721010A9E630                     JB0OA3J0
\\.\PhysicalDrive1 12  Samsung SSD 850 EVO mSATA 1TB            EMT41B6Q
No more disks present ending scan

How to make it work properly under recovery image?

I'm using 1.15.1 version of the recovery image.

[r0m30]

This is a bug, I'm not sure where it is from this. Do you have a third drive or only the two?

[Defozo]

I have only the two drives.

[r0m30]

OK, the timings indicate a pretty tight loop when it reports the undocumented segment. I've had drives with vendor segments and never experienced this.

[bakantor]

In case it helps, I had a very similar issue (Segmentation Fault errors) and reflashed the memory stick I was using to boot the computer and run the bootable rescue system and the issue went away.

[GreenReaper]

I encountered the same issues, having dd'd the image to a USB drive which previously contained data and rebooted to it. If I remove the USB drive before executing linuxpba in the recovery OS, there is no such issue (although there are lots of "Destroying" and "Creating" debug messages).

There's no indication on the wiki that removal of the USB drive is necessary to test the pba.

[GreenReaper]

The relevant code is here. There seems to a lack of sanity checking of the response - i.e. "TODO: check header version" and "/ should do something here /" - it just treats it as if it is a valid header and sequence of bodies. But should a null feature be valid? Zero lengths? It's a sign that something has gone wrong.

Consider what might happen if a buffer filled with debug memset fill - or just junk - was returned and interpreted as a Discovery0Header. Let alone something deliberately bad. It doesn't seem to check the sanity of hdr->length against, say, MIN_BUFFER_LENGTH, and if the length is non-sane it might just cause you to skip over a huge amount of memory and then start indexing well off the actual array.

If it gets into zeroed memory it'll naturally keep going, because "body->TPer.length" is 0, and 0+4 is 4. Even though I'm guessing 0 should not be a valid TPer.length. Then it runs off the address space. 😅

As it is, this is effectively a DoS which stops drives after that being listed, and certain other operations from returning visible data - being triggered by accident, simply by leaving a flash drive in place, Someone malicious could perhaps do worse, if not with this then with other code which doesn't check for sanity. Of course, they'd need access to attach a drive, but that might be OK if they want to steal keys from an unwary operator, and it might be feasible to stick a [virtual?] USB key in without being noticed.

[GreenReaper]

Here's what debug shows it's actually processing:

This seems to be a valid structure from a Samsung 840 EVO

0000 000000a4 00000001 00000000 00000000 ................ 0010 00000000 00000000 00000000 00000000 ................ 0020 00000000 00000000 00000000 00000000 ................ 0030 0001100c 11000000 00000000 00000000 ................ 0040 0002100c 09000000 00000000 00000000 ................ 0050 0003101c 00000000 00000000 00000200 ................ 0060 00000000 00000001 00000000 00000000 ................ 0070 02001010 10040001 00000000 00000000 ................ 0080 00000000 0202100c 00000009 00a00000 ................ 0090 00000001 02031010 10040001 00000400 ................ 00a0 09000000 ....

And this is . . . the master boot record of the Flash drive, which it returned as the response. Since the first four bytes are interpreted as length, it's guaranteed to never reach epos before it crashes.

0000 fa31c08e d88ed0bc 007c89e6 0657528e .1.......|...WR. 0010 c0fbfcbf 0006b900 01f3a5ea 20060000 ............ ... 0020 52b441bb aa5531c9 30f6f9cd 13721381 R.A..U1.0....r.. 0030 fb55aa75 0dd1e973 0966c706 8d06b442 .U.u...s.f.....B 0040 eb155ab4 08cd1383 e13f510f b6c640f7 ..Z......?Q...@. 0050 e1525066 31c06699 e86600e8 21014d69 .RPf1.f..f..!.Mi 0060 7373696e 67206f70 65726174 696e6720 ssing operating 0070 73797374 656d2e0d 0a666066 31d2bb00 system...ff1... 0080 7c665266 5006536a 016a1089 e666f736 |fRfP.Sj.j...f.6 0090 f47bc0e4 0688e188 c592f636 f87b88c6 .{.........6.{.. 00a0 08e141b8 01028a16 fa7bcd13 8d641066 ..A......{...d.f 00b0 61c3e8c4 ffbebe7d bfbe07b9 2000f3a5 a......}.... ... 00c0 c3666089 e5bbbe07 b9040031 c05351f6 .f........1.SQ. 00d0 07807403 4089de83 c310e2f3 48745b79 ..t.@.......Ht[y 00e0 39595b8a 47043c0f 7406247f 3c057522 9Y[.G.<.t.$.<.u" 00f0 668b4708 668b5614 6601d066 21d27503 f.G.f.V.f..f!.u. 0100 6689c2e8 acff7203 e8b6ff66 8b461ce8 f.....r....f.F.. 0110 a0ff83c3 10e2cc66 61c3e862 004d756c .......fa..b.Mul 0120 7469706c 65206163 74697665 20706172 tiple active par 0130 74697469 6f6e732e 0d0a668b 44086603 titions...f.D.f. 0140 461c6689 4408e830 ff721381 3efe7d55 F.f.D..0.r..>.}U 0150 aa0f8506 ffbcfa7b 5a5f07fa ffe4e81e .......{Z_...... 0160 004f7065 72617469 6e672073 79737465 .Operating syste 0170 6d206c6f 61642065 72726f72 2e0d0a5e m load error...^ 0180 acb40e8a 3e6204b3 07cd103c 0a75f1cd ....>b.....<.u.. 0190 18f4ebfd acb40e8a 3e6204b3 07cd103c ........>b.....< 01a0 0a75f1cd 18f4ebfd 00000000 00000000 .u.............. 01b0 00000000 00000000 47c6a804 00008001 ........G....... 01c0 01000cfe ffce3f00 0000c117 ef000000 ......?......... 01d0 00000000 00000000 00000000 00000000 ................ 01e0 00000000 00000000 00000000 00000000 ................ 01f0 00000000 00000000 00000000 000055aa ..............U. 0200 00000000 00000000 00000000 00000000 ................ ... [more 0's]

0800 6d000000 00000002 07040000 00000000 m............... 0810 8b000000 00000000 18000266 756c6c00 ...........full. 0820 06040000 00000000 8c000000 00000000 ................ 0830 1800027a 65726f00 05040000 00000000 ...zero......... 0840 8d000000 00000000 18000270 6f727400 ...........port. 0850 04040000 00000000 8e000000 00000000 ................ 0860 1800026e 756c6c00 03040000 00000000 ...null......... 0870 8f000000 00000000 1800026d 656d0002 ...........mem.. 0880 02040000 00000000 90000000 00000000 ................ 0890 20000276 67615f61 72626974 65720002 ..vga_arbiter.. [more 0's]

0970 00000000 00000000 00080000 9e070000 ................ 0980 00000000 00000000 a0cdbd00 00000000 ................ 0990 700d0000 00000000 21000000 00000000 p.......!....... 09a0 38594500 00000000 03000000 00000000 8YE............. 09b0 90cdbd00 00000000 41020000 00000000 ........A....... 09c0 00d8bd00 00000000 581b70c6 9a7f0000 ........X.p..... [more 0's]

0bc0 00000000 00000000 31000000 00000000 ........1....... 0bd0 781b70c6 9a7f0000 781b70c6 9a7f0000 x.p.....x.p..... 0be0 c0cfbd00 00000000 c0cfbd00 00000000 ................ 0bf0 40020000 00000000 10080000 00000000 @............... [more 0's and a bunch more junk until it ends at 1fc00]