Bugzilla – Bug 1217134
LTP ioctl01.c: ioctl(TCGETS) does not check validity of pointer argument on PPC64LE
Last modified: 2024-02-20 16:55:40 UTC
## Observation openQA test in scenario sle-15-SP6-Online-ppc64le-ltp_syscalls@ppc64le-virtio fails in [ioctl01](https://openqa.suse.de/tests/12799195/modules/ioctl01/steps/7) ## Test suite description This crash should happen during check ioctl with wrong command INVAL_IOCTL base log trace output. #define INVAL_IOCTL 9999999 ioctl(fd, INVAL_IOCTL, &termio) <<<<< susetest:~/ltp # gdb ./testcases/kernel/syscalls/ioctl/ioctl01 /var/core/ioctl01.12434.1699946749 GNU gdb (GDB; SUSE Linux Enterprise 15) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "ppc64le-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://bugs.opensuse.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./testcases/kernel/syscalls/ioctl/ioctl01... warning: Can't open file /dev/shm/ltp_ioctl01_12433 (deleted) during file-backed mapping note processing [New LWP 12434] Core was generated by `./testcases/kernel/syscalls/ioctl/ioctl01 '. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fffb39da80c in tcgetattr () from /lib64/libc.so.6 Missing separate debuginfos, use: zypper install glibc-debuginfo-2.31-150300.63.1.ppc64le <<<<<<<<< (gdb) i threads Id Target Id Frame * 1 LWP 12434 0x00007fffb39da80c in tcgetattr () from /lib64/libc.so.6 (gdb) bt #0 0x00007fffb39da80c in tcgetattr () from /lib64/libc.so.6 <<<<<<< #1 0x00007fffb39db750 in ioctl () from /lib64/libc.so.6 #2 0x0000000010005698 in verify_ioctl (i=<optimized out>) at ioctl01.c:62 #3 0x0000000010015660 in run_tests () at tst_test.c:1413 #4 testrun () at tst_test.c:1479 #5 fork_testrun () at tst_test.c:1608 #6 0x0000000010018058 in tst_run_tcases (argc=<optimized out>, argv=<optimized out>, self=<optimized out>) at tst_test.c:1704 #7 0x00000000100054a0 in main (argc=<optimized out>, argv=<optimized out>) at ../../../../include/tst_test.h:401 ## LTP failed log LTP log: tst_test.c:1690: TINFO: LTP version: 20230929 tst_test.c:1576: TINFO: Timeout per run is 0h 00m 30s ioctl01.c:63: TPASS: File descriptor is invalid (termio) : EBADF (9) ioctl01.c:63: TPASS: File descriptor is invalid (termios) : EBADF (9) ioctl01.c:63: TPASS: Termio address is invalid : EFAULT (14) tst_test.c:1634: TBROK: Test killed by SIGSEGV! Another issue is when i try to install glibc debuginfos(base gdb above notification) but encounter error. susetest:~ # zypper install glibc-debuginfo-2.31-150300.63.1.ppc64le Refreshing service 'Basesystem_Module_15_SP6_ppc64le'. Refreshing service 'Desktop_Applications_Module_15_SP6_ppc64le'. Refreshing service 'Development_Tools_Module_15_SP6_ppc64le'. Refreshing service 'SUSE_Linux_Enterprise_Server_15_SP6_ppc64le'. Refreshing service 'Server_Applications_Module_15_SP6_ppc64le'. Loading repository data... Reading installed packages... 'glibc-debuginfo-2.31-150300.63.1.ppc64le' not found in package names. Trying capabilities. No provider of 'glibc-debuginfo-2.31-150300.63.1.ppc64le' found. ['--plus-content debug'?] Resolving package dependencies... Nothing to do. susetest:~ # zypper ref Repository 'SLE-Module-Basesystem15-SP6-Debuginfo-Pool' is up to date. Repository 'SLE-Module-Basesystem15-SP6-Debuginfo-Updates' is up to date. Repository 'SLE-Module-Basesystem15-SP6-Pool' is up to date. Retrieving repository 'SLE-Module-Basesystem15-SP6-Source-Pool' metadata .........................................................................[done] Building repository 'SLE-Module-Basesystem15-SP6-Source-Pool' cache ..............................................................................[done] Repository 'SLE-Module-Basesystem15-SP6-Updates' is up to date. Retrieving repository 'SLE-Module-Desktop-Applications15-SP6-Debuginfo-Pool' metadata ............................................................[done] Building repository 'SLE-Module-Desktop-Applications15-SP6-Debuginfo-Pool' cache .................................................................[done] Retrieving repository 'SLE-Module-Desktop-Applications15-SP6-Debuginfo-Updates' metadata .........................................................[done] Building repository 'SLE-Module-Desktop-Applications15-SP6-Debuginfo-Updates' cache ..............................................................[done] Repository 'SLE-Module-Desktop-Applications15-SP6-Pool' is up to date. Retrieving repository 'SLE-Module-Desktop-Applications15-SP6-Source-Pool' metadata ...............................................................[done] Building repository 'SLE-Module-Desktop-Applications15-SP6-Source-Pool' cache ....................................................................[done] Repository 'SLE-Module-Desktop-Applications15-SP6-Updates' is up to date. Repository 'SLE-Module-DevTools15-SP6-Debuginfo-Pool' is up to date. Repository 'SLE-Module-DevTools15-SP6-Debuginfo-Updates' is up to date. Repository 'SLE-Module-DevTools15-SP6-Pool' is up to date. Retrieving repository 'SLE-Module-DevTools15-SP6-Source-Pool' metadata ...........................................................................[done] Building repository 'SLE-Module-DevTools15-SP6-Source-Pool' cache ................................................................................[done] Repository 'SLE-Module-DevTools15-SP6-Updates' is up to date. Repository 'SLES15-SP6-15.6-0' is up to date. Retrieving repository 'SLE-Product-SLES15-SP6-Debuginfo-Pool' metadata ...........................................................................[done] Building repository 'SLE-Product-SLES15-SP6-Debuginfo-Pool' cache ................................................................................[done] Retrieving repository 'SLE-Product-SLES15-SP6-Debuginfo-Updates' metadata ........................................................................[done] Building repository 'SLE-Product-SLES15-SP6-Debuginfo-Updates' cache .............................................................................[done] Repository 'SLE-Product-SLES15-SP6-Pool' is up to date. Retrieving repository 'SLE-Product-SLES15-SP6-Source-Pool' metadata ..............................................................................[done] Building repository 'SLE-Product-SLES15-SP6-Source-Pool' cache ...................................................................................[done] Repository 'SLE-Product-SLES15-SP6-Updates' is up to date. Retrieving repository 'SLE-Module-Server-Applications15-SP6-Debuginfo-Pool' metadata .............................................................[done] Building repository 'SLE-Module-Server-Applications15-SP6-Debuginfo-Pool' cache ..................................................................[done] Retrieving repository 'SLE-Module-Server-Applications15-SP6-Debuginfo-Updates' metadata ..........................................................[done] Building repository 'SLE-Module-Server-Applications15-SP6-Debuginfo-Updates' cache ...............................................................[done] Repository 'SLE-Module-Server-Applications15-SP6-Pool' is up to date. Retrieving repository 'SLE-Module-Server-Applications15-SP6-Source-Pool' metadata ................................................................[done] Building repository 'SLE-Module-Server-Applications15-SP6-Source-Pool' cache .....................................................................[done] Repository 'SLE-Module-Server-Applications15-SP6-Updates' is up to date. Repository 'qa-head' is up to date. All repositories have been refreshed.
The above bugreport is incorrect. The ioctl01 test was recently rewritten to include termios subtests which trigger the following failure: openpty(&master, &slave, NULL, NULL, NULL); ret = ioctl(master, TCGETS, (struct termios *)-1); The test expects that the ioctl() call will fail with EFAULT like TCGETA does with the exact same invalid pointer value. But it sends SIGSEGV to the test process instead. The INVAL_IOCTL subtest mentioned above does not get to run due to the above segfault. All supported SLE versions are affected on PPC64LE (SLE-12SP5+), including SLE-15SP6. Other archs are not affected.
perhaps for Jiri Slaby?
TCGETS is of course checked. So: can I see the crash (full dmesg output)?
(In reply to Jiri Slaby from comment #5) > TCGETS is of course checked. So: can I see the crash (full dmesg output)? It's check on all archs except PPC64LE. There must be some platform-specific mess-up. There isn't much dmesg output. It's a userspace segfault, not a kernel crash: https://openqa.suse.de/tests/12988674/logfile?filename=serial0.txt OpenQA::run_ltp.pm: Starting ioctl01 [ 957.493390][T21251] ioctl01[21251]: segfault (11) at 37 nip 7fff9505a80c lr 7fff9505b750 code 1 in libc-2.31.so[7fff94f30000+200000] [ 957.493556][T21251] ioctl01[21251]: code: 7c0802a6 81210054 81610030 80c10034 80e10038 387f0011 8901004f 81410050 [ 957.493642][T21251] ioctl01[21251]: code: 38a00013 3881003c f8010080 8001002c <913f0038> 917f0004 90df0008 90ff000c OpenQA::run_ltp.pm: Starting ioctl02
glibc translates it to __ioctl (int fd, unsigned long int request, ...) { void *arg; va_list ap; int result; va_start (ap, request); arg = va_arg (ap, void *); switch (request) { case TCGETS: result = __tcgetattr (fd, (struct termios *) arg); break; whih is /* Put the state of FD into *TERMIOS_P. */ int __tcgetattr (int fd, struct termios *termios_p) { struct __kernel_termios k_termios; int retval; retval = INLINE_SYSCALL (ioctl, 3, fd, TCGETS, &k_termios); if (__glibc_likely (retval == 0)) { termios_p->c_iflag = k_termios.c_iflag; termios_p->c_oflag = k_termios.c_oflag; termios_p->c_cflag = k_termios.c_cflag; termios_p->c_lflag = k_termios.c_lflag; termios_p->c_line = k_termios.c_line; #ifdef _HAVE_STRUCT_TERMIOS_C_ISPEED # ifdef _HAVE_C_ISPEED So basically glibc maps the ioctl TCGETS systemcall in its own code, uses a different struct for the kernel and then the later copy crashes. I think this is not a real valid test when passing in invalid pointers anything could happen, garbage in/garbage out style.
it seems only powerpc does this ioctl translation of termios related stuff, so t hats why its only visibile on ppc.
Ah, sure, ppc is currently the only arch not implementing TCGETS2. This is WONTFIX for SLE, but let me fix that in upstream.
(In reply to Jiri Slaby from comment #9) > Ah, sure, ppc is currently the only arch not implementing TCGETS2. That's not the problem. ppc defines struct ktermios a weird way. So translation has to be done. (There is nothing we can do here.)
(In reply to Jiri Slaby from comment #9) > Ah, sure, ppc is currently the only arch not implementing TCGETS2. > > This is WONTFIX for SLE, but let me fix that in upstream. @Jiri, any progress with upstream? Please post link to the patch here or Cc me, when you get time for it.
Petr Vorel from comment #11) > @Jiri, any progress with upstream? Please post link to the patch here or Cc > me, when you get time for it. The issue is WONTFIX. The only thing we can do is change or disable the test because data conversion in Glibc is unavoidable due to PPC kernel API weirdness.
The recommended way to check memory access from userspace is to submit that memory region to a write() to pipe. That could convert the sigsegv into EFAULT at the cost of opening a pipe.
(In reply to Marcus Meissner from comment #8) > it seems only powerpc does this ioctl translation of termios related stuff, > so t hats why its only visibile on ppc. I see: sysdeps/unix/sysv/linux/powerpc/internal-ioctl.h (TCGETS) (In reply to Michal Suchanek from comment #13) > The recommended way to check memory access from userspace is to submit that > memory region to a write() to pipe. That could convert the sigsegv into > EFAULT at the cost of opening a pipe. Thanks for a hint.