We have published [Qubes Security Bulletin (QSB) 089: Qrexec: Memory corruption in service request handling](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-089-2023.txt). The text of this QSB and its accompanying cryptographic signatures are reproduced below. For an explanation of this announcement and instructions for authenticating this QSB, please see the end of this announcement.
## Qubes Security Bulletin 089
```
---===[ Qubes Security Bulletin 089 ]===---
2023-05-11
Qrexec: Memory corruption in service request handling
If the process is not reused, just an update without restarting anything is enough, isn’t it? (This wouldn’t be the case if the process was forking from a zygote.)
After the update, I got a shower of notifications “Failed to execute qubes.WindowIconUdater (from to dom0)”, probably for each running domU qube. But this looks like a temporary issue, as QRPc seems to continue working, either for newly launched qubes and for qubes launched before update.
If the process is not reused, just an update without restarting anything is
enough, isn't it? (This wouldn't be the case if the process was forking
from a zygote.)
Marek has previously told me that only Xen and Kernel updates require a reboot. FWIW, `needs-restarting -r` also didn't detect anything requiring a restart.
After the update, I got a shower of notifications “Failed to execute
qubes.WindowIconUdater (from <qube name> to dom0)”, probably for each
running domU qube.
Same.
But this looks like a temporary issue, as QRPc seems to
continue working, either for newly launched qubes and for qubes launched
before update.
The process forks for each request, so one will need to kill all
currently-running qrexec-daemon processes to be protected from this
vulnerability. The simplest way to do this is to reboot all domUs.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab