Sysinfo syscalls can loop forever

[Martin Decky]

The current way sysinfo syscall are used (first get the required buffer size, then supply the buffer with the possibility to fail if the size of the data has changed in the meantime) can theoretically lead to an unbounded loop.

Since non-fixed sysinfo data is usually not essential, use less strict checks.

[Jiri Svoboda]

I don't think it's okay to say that some data is not essential and therefore it does not matter if it's broken or inconsistent. In some specific cases where the sysinfo data contain a list of fixed-size entries you would just get a subset of the entries. In the general case, however, you could get truncated (invalid) data.

I think we should fix the problem without sacrificing correctness of the data. I can think of at least two approaches.

(1) Start with a small buffer (say first get the required size). Then get the data and every time the data does not fit in the buffer, double the size of the buffer and repeat. This terminates in O(log N) steps where N is an upper bound on the size of the data.

(2) Don't copy the data directly into user memory. Copy it in a kernel buffer and let user space manage that buffer (copy memory out and destroy it). This would probably require some caution to avoid possibility of kernel memory exhaustion.

[Martin Decky]

I understand your concern for the general case. However, currently the sysinfo is used to get a list of fixed-size entries for statistical purposes or constant strings. In both of these cases it is safe to accept truncated data and decide/make sure (in user space) that the data is valid (checking that the size is of a certain granularity and NULL-terminating the string).

The rewritten SYS_SYSINFO_GET_DATA provides means for additional checks of the returned data size in case sysinfo is going to be used for passing different kind of data.

The possibility of infinite looping is thus avoided in mainline revision 831.