On Mon, Oct 18, 2021 at 04:42:04PM -0400, Rich Felker wrote:
On Mon, Oct 18, 2021 at 05:26:35PM +0200, Arnd Bergmann wrote:
On Mon, Oct 18, 2021 at 5:08 PM Rich Felker dalias@libc.org wrote:
On Mon, Oct 18, 2021 at 04:58:03PM +0200, Takashi Iwai wrote:
On Mon, 18 Oct 2021 16:43:00 +0200, Rich Felker wrote:
No, I don't think so. The musl translator is to translate between the time64 ioctl structures and the old time32 ones for the sake of executing on an old kernel. Up til now, it has been broken comparably to how 32-bit binaries running in compat mode on a 64-bit kernel were broken: the code in musl translated the time64 structure to (and back from) the time32 one assuming the intended padding. But the application was using the actual kernel uapi struct where the padding was (and still is) illogical. Thus, nothing was built with the wrong ABI; it's only the musl-internal translation logic that was wrong (and only pre-time64 kernels are affected).
The attached patch should fix it, I think.
- int adj = BYTE_ORDER==BIG_ENDIAN ? 4 : 0;
- if (dir==W) {
memcpy(old+68, new+72+adj, 4);memcpy(old+72, new+72+4+2*adj, 4);I think that should be "new+72+4+3*adj": the "2*adj" would be what the code does already for the originally intended format.
Well for little endian either would work (because adj is 0 :) but yes there are 3 such paddings before the second member on big endian, so it should be 3.
How about this? It avoids open coding the logic and handles it as 2 4-byte substructures with endian-specific offsets.
Rich