bug: Initial setup of OPAL drive fails (due to out-of-bounds `userid` reads)

[mynetz]

I have an OPAL 2.0 drive that works fine with the old sedutil-cli binary release but doesn't work well with the current stable tag 1.49.13 (and probably older, didn't do a bisect)

Error output:

sedutil-cli --initialSetup <password> /dev/nvme0n1
method status code NOT_AUTHORIZED
Set table Failed /dev/nvme0n1
Unable to enable user User1060250974A6000022 /dev/nvme0n1
enable user failed /dev/nvme0n1

Note: The drive has previously been reset by:

sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID <PSID> /dev/nvme0n1

The User1060250974A6000022 string is an interesting hint. The 060250974A6000022 part is the serial number. Investigating the code does not yield a result where the username might be build/extended by any drive information.

But, I saw this:

sedutil/Common/DtaDevOpal.cpp

Lines 279 to 284 in 1b0633a

	char buf[5] = { 'U','s','e','r','1' };
	if ((lastRC = enableUser(true, password, buf)) != 0) {
	LOG(E) << "enable user failed " << dev;
	return lastRC;
	}

The buf[] is used in called function as char * and ends up in functions like atoi() that expect it to be a \0-terminated string. Hence reads on that buffer may read additional information from the stack until a \0 is found.

sedutil/Common/DtaDevOpal.cpp

Lines 1075 to 1079 in 1b0633a

	if (!memcmp("User", userid, 4)) {
	userData.push_back(0x00);
	userData.push_back(0x03);
	userData.push_back(0x00);
	userData.push_back(atoi(&userid[4]) & 0xff);

In my case this means additional integer character that increase the converted number.

Note: When running with -v the behaviour changes and I can initialise the drive. But probably only due to some "better" random data.

User1<B0>�4u^? has been enabled /dev/nvme0n1

The ASCII is not a valid number hence atoi will not convert it and the result is the expected "1". However in the printout we can see still the out-of-bounds read of userid.