Update to 1.9.24. Disable command mode in long-running service (--no-command flag). Enable PrivateNetwork=true in systemd service. Remove SELinux policy module (no longer needed without command mode).
Fix rpminspect.yaml: use annocheck failure_severity instead of inspections toggle (annocheck is a security inspection and cannot be disabled via inspections section)
Update to 1.9.23-2: - Add SELinux policy module to allow semaphore creation in /dev/shm - Add rpminspect.yaml to waive pre-existing annocheck false positive
Security fixes in 1.9.23-1: - Use O_EXCL with sem_open to prevent semaphore pre-planting attacks - Fix OOB memory access in safein()/safeout() on socket errors - Reject command socket connections from different user namespaces - Use O_NOFOLLOW for PID file to prevent symlink attacks - Open random device with O_CLOEXEC, restrict semaphore to 0600 - Fix stale semaphore recovery after SIGKILL - Fix compilation when NO_COMMAND_MODE is defined
Update to 1.9.23 — security hardening: - Use O_EXCL with sem_open to prevent semaphore pre-planting attacks - Fix OOB memory access in safein()/safeout() on socket errors - Reject command socket connections from different user namespaces - Use O_NOFOLLOW for PID file to prevent symlink attacks - Open random device with O_CLOEXEC, restrict semaphore to 0600 - Fix stale semaphore recovery after SIGKILL - Fix compilation when NO_COMMAND_MODE is defined
Please log in to add feedback.
This update has been submitted for testing by jhladky.
This update's test gating status has been changed to 'ignored'.
This update has obsoleted haveged-1.9.23-3.fc43, and has inherited its bugs and notes.
This update has been pushed to testing.
I suspect this may be causing the FreeIPA server upgrade failures we noticed in Rawhide testing. Filing -1 to prevent automatic push while I confirm.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
I've investigated the bug further and determined precisely what's going on, I think. It requires quite a precise configuration to trigger - you have to have started haveged.service , but not have it enabled - but it's quite bad if you hit it. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=2491739
This update has been obsoleted by haveged-1.9.25-1.fc43.