Cassandrich
@marcan @aep If it's in any widely-deployed-in-the-wild kernels...
May 12, 2023 at 8:46pmWeb
Show threadArvid E. PiccianiMay 12, 2023

@dalias @marcan It's pretty clear the buggy caller intended to pass 0, so i think the fix should at least honor that intention. This is a very common bug for people used to C++ zeroing out optional args.

I still think the correct fix is to assume any number above ulimit should be ignored because it doesn't work anyway, so any legitimate code would have never worked.

Show threadCassandrichMay 12, 2023
@aep @marcan The legitimate code could very well have been probing the limit for the guaranteed EINVAL if it's exceeded.
Show threadArvid E. PiccianiMay 12, 2023
@dalias @marcan good point, then let's maybe meet in the middle. Make it fail below 32bit and make it assume 0 above 32 bit. This works on little endian because the further away from the end of vararg, the more likely you get trash.
Show threadCassandrichMay 12, 2023
@aep @marcan It's going to be in an argument register. Depending on target ABI, upper bits of a 32-bit arg might be filled with junk anyway - it varies by arch whether the caller has to zero or sign extend them or whether it's callee's responsibility to ignore what's there.