From: Oleg Nesterov > Sent: 14 April 2021 17:56 > > On 04/14, David Laight wrote: > > > > From: Oleg Nesterov > > > Sent: 14 April 2021 16:08 > > > > > > Add audit maintainers... > > > > > > On 04/14, He Zhe wrote: > > > > > > > > When 32-bit userspace application is running on 64-bit kernel, the > > > > 32-bit > > > > syscall return code would be changed from u32 to u64 in > > > > regs_return_value > > > > and then changed to s64. Hence the negative return code would be treated > > > > as a positive number and results in a non-error in, for example, audit > > > > like below. > > > > > > Sorry, can understand. At least on x86_64 even the 32-bit syscall returns > > > long, not u32. > > > > > > Hmm. And afaics on x86 is_compat_task() is only defined if !CONFIG_COMPAT, > > > so this patch looks wrong anyway. > > > > And, as with the other patch a x64_64 64bit process can make both types > > of 32bit system call - so it needs to depend on the system call entry type > > not any type of the task. > > I don't understand... but iirc is_compat_task() used to check TS_COMPAT and > this is what we need to detect the 32-bit syscall.
Not on X86_64. The syscall entry code sets the type on the current system call entry. So a process that is created as a 64bit process can make both i386 and x32 system calls as well as normal 64bit ones. > But it looks deprecated, > I think in_compat_syscall() should be used instead. That does the right checks on x86. Most code doesn't need to know about the subtle difference between normal 32bit calls and x32 ones. > But this doesn't matter, I still can't understand the problem. Dunno, I only know the 'fix' is borked. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)