if (nbytes < sizeof(*hwrpb))
return -1;
if (copy_to_user(buffer, hwrpb, nbytes) != 0)
return -2;
if (nbytes > sizeof(*hwrpb))
if (copy_to_user(buffer, hwrpb, sizeof(*hwrpb)) != 0)
and sizeof(hwrpb) is now 16 bytes, then you will be copying 12 bytes of data too many from the caller, potentially reading into memory it doesn't own. I would say that should be avoided.
The better solution I believe would be to only copy the minimum amount of bytes supported by caller & callee. So:
nbytes = MIN(nbytes, sizeof(hwrpb));
Which should ensure backwards and forwards compatibility, assuming the version info of hwrpb->size is respected then the fact that part of the hwrpb struct isn't initialized shouldn't matter.
if (nbytes < sizeof(*hwrpb))
Recall that the API is intended to be used like this:
struct hwrbp buf;
getsysinfo(GSI_GET_HWRPB, &buf, sizeof(buf), /* .. */);
if (nbytes != sizeof(\*hwrpb)) return -1;
I would agree with you if the kernel had some other mechanism to pass the size of the buffer that was actually filled to the client (like e.g. the read() syscall does) but the getsysinfo() API doesn't return that data, so the kernel must either fill the buffer entirely or return failure.*
> I would agree with you if the kernel had some other mechanism to pass the size of the buffer that was actually filled to the client (like e.g. the read() syscall does) but the getsysinfo() API doesn't return that data, so the kernel must either fill the buffer entirely or return failure.
As you mention, this struct is versioned. Userspace can tell how much of the struct was filled by checking the size field (hwrpb->size).
> But allowing nbytes < sizeof(*hwrpb) has the benefit that the kernel developers can add fields at the end of the struct without breaking backward compatibility with older applications.
That's a related but separate issue. Backward compatibility can be handled by switching on nbytes or by copying fewer bytes with a carefully designed struct. It's not clear that backward compatibility was the original intention of this code, the original intention more seems to be sanitizing tainted input. This struct has not changed in at least 16 years.
It was only deemed incorrect because of an information leak. Not because it's a valid use-case for user space to copy smaller portions of *hwrpb into user space. https://github.com/torvalds/linux/commit/21c5977a836e399fc71...