229 backport for race between explicit mount and handling automount
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
systemd (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
High
|
Unassigned | ||
Zesty |
Fix Released
|
Medium
|
Unassigned | ||
Artful |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
In systemd prior to 234 a race exists between .mount and .automount units such that automount requests from kernel may not be serviced by systemd resulting in kernel holding the mountpoint and any processes that try to use said mount will hang. A race like this may lead to denial of service, until mount points are unmounted.
[Testcase]
Create a race between .mount and .automount units, such that automout request is serviced after .mount unit has been started. Observe a hang.
More detailed steps are available at https:/
[Butfix]
Cherrypick upstream commit https:/
[Regression Potential]
The underlying logic of starting/
[Original Bug report / request]
Hi,
We have a blocking issue in systemd for the following release
```
NAME="Ubuntu"
VERSION="16.04.3 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.3 LTS"
VERSION_ID="16.04"
HOME_URL="http://
SUPPORT_URL="http://
BUG_REPORT_URL="http://
VERSION_
UBUNTU_
```
This release runs systemd229, we are affected by the following auto-mouting race condition
```
https:/
```
Is back porting the fix to the release 229 an option?
Regards.
CVE References
Changed in systemd (Ubuntu Xenial): | |
importance: | Undecided → High |
status: | New → Confirmed |
description: | updated |
Status changed to 'Confirmed' because the bug affects multiple users.