Description of problem: LTP/semctl09 failed on RHEL-8.4. semctl09.c:67: TINFO: Test SYS_semctl syscall semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user semctl09.c:56: TCONF: syscall(394) __NR_semctl not supported semctl09.c:187: TWARN: semctl(12, 0, 0,...) failed: EPERM (1) tst_test.c:1263: TINFO: Timeout per run is 0h 05m 00s semctl09.c:70: TINFO: Test libc semctl() semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified by the caller to kernel semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified by the caller to kernel Version-Release number of selected component (if applicable): glibc-2.28-127.el8.x86_64 Additional info: https://sourceware.org/bugzilla/show_bug.cgi?id=26637
commit 574500a108be1d2a6a0dc97a075c9e0a98371aba Author: Dmitry V. Levin <ldv> Date: Tue Sep 29 14:10:20 2020 -0300 sysvipc: Fix SEM_STAT_ANY kernel argument pass [BZ #26637] Handle SEM_STAT_ANY the same way as SEM_STAT so that the buffer argument of SEM_STAT_ANY is properly passed to the kernel and back. The regression testcase checks for Linux specifix SysV ipc message control extension. For IPC_INFO/SEM_INFO it tries to match the values against the tunable /proc values and for SEM_STAT/SEM_STAT_ANY it check if the create message queue is within the global list returned by the kernel. Checked on x86_64-linux-gnu and on i686-linux-gnu (Linux v5.4 and on Linux v4.15). Co-authored-by: Adhemerval Zanella <adhemerval.zanella>
No regressions have been found.
Hi Carlos, I am Eva, a tech writer for the devtools team. Nice to meet you! This is my first draft for this bugfix RN, and I'd be very happy if you could give some feedback on this. Thank you very much! .The `semctl` system call wrapper in `glibc` now treats `SEM_STAT_ANY` like `SEM_STAT` Previously, the `semctl` system call wrapper in `glibc` did not treat the kernel argument `SEM_STAT_ANY` like `SEM_STAT`. As a result, `glibc` did not properly pass the address of the result object `struct semid_ds` to the kernel so that the kernel failed to update it properly. With this update, `SEM_STAT_ANY` is now treated like `SEM_STAT` by glibc, and as a result, applications can obtain `struct semid_ds` data using `SEM_STAT_ANY`.
(In reply to Eva-Lotte Gebhardt from comment #11) > .The `semctl` system call wrapper in `glibc` now treats `SEM_STAT_ANY` like > `SEM_STAT` > > Previously, the `semctl` system call wrapper in `glibc` did not treat the > kernel argument `SEM_STAT_ANY` like `SEM_STAT`. As a result, `glibc` did not > properly pass the address of the result object `struct semid_ds` to the > kernel so that the kernel failed to update it properly. With this update, > `SEM_STAT_ANY` is now treated like `SEM_STAT` by glibc, and as a result, > applications can obtain `struct semid_ds` data using `SEM_STAT_ANY`. This looks good to me. Thanks for the review.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: glibc security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:4358