On Thursday 01 July 2010 06:57:07 Andreas Dilger wrote: > If a future kernel gets a new static field at st_extra_results (say > unsigned long long st_ino_high) with a new flag XSTAT_REQUEST_INO_HIGH > 0x000040000ULL the kernel will think that the old app is requesting > this field, and will fill in the 64-bit field at st_extra_results[1] > (which the old app didn't allocate space for, nor does it understand) > and may get a segfault, or stack smashing, or random heap corruption. That depends on whether the struct contains a 'buflen' field or not (it may be part of the struct, as a syscall argument, or in a second struct). I argue that it should not contain a buflen field and that users should consequently not set bits that they don't know about to prevent the scenario you describe. If the buflen stays in, it will prevent the stack smashing part, but add extra complexity in the interface, which can cause other problems. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
