Public bug reported:
SRU Justification
Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The
problem is that we only take a reference to the mount of the underlay, i.e. the
filesystem that is *under* the shiftfs mark mount. This means when someone
performs a shiftfs mark mount, then a shiftfs overlay mount and then
immediately unmounts the shiftfs mark mount we muck with invalid memory since
shiftfs_put_super might have already been called freeing that memory.
Fix: Copy up the passthrough mount settings of the mark mount point to the
shiftfs overlay.
One solution would be to start reference counting which is overkill. We only
care about the passthrough mount option of the mark mount. And we only need it
to verify that on remount the new passthrough options of the shiftfs overlay
are a subset of the mark mount's passthrough options. In other scenarios we
don't care. So copying up is good enough and also only needs to happen once on
mount, i.e. when a new superblock is created and the .fill_super method is
called.
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Christian Brauner (cbrauner)
Status: In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
** Changed in: linux (Ubuntu)
Status: New => In Progress
** Description changed:
- We currently keep a reference to the shiftfs mark mount's
+ SRU Justification
+
+
+ Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The
problem is that we only take a reference to the mount of the underlay, i.e. the
filesystem that is *under* the shiftfs mark mount. This means when someone
performs a shiftfs mark mount, then a shiftfs overlay mount and then
immediately unmounts the shiftfs mark mount we muck with invalid memory since
shiftfs_put_super might have already been called freeing that memory.
+
+ Fix: Copy up the passthrough mount settings of the mark mount point to the
shiftfs overlay.
+ One solution would be to start reference counting which is overkill. We only
care about the passthrough mount option of the mark mount. And we only need it
to verify that on remount the new passthrough options of the shiftfs overlay
are a subset of the mark mount's passthrough options. In other scenarios we
don't care. So copying up is good enough and also only needs to happen once on
mount, i.e. when a new superblock is created and the .fill_super method is
called.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1824735
Title:
shiftfs: use after free when checking mount options
Status in linux package in Ubuntu:
In Progress
Bug description:
SRU Justification
Impact: We currently keep a reference to the shiftfs mark mount's
shiftfs_super_info which was stashed in the superblock of the mark mount. The
problem is that we only take a reference to the mount of the underlay, i.e. the
filesystem that is *under* the shiftfs mark mount. This means when someone
performs a shiftfs mark mount, then a shiftfs overlay mount and then
immediately unmounts the shiftfs mark mount we muck with invalid memory since
shiftfs_put_super might have already been called freeing that memory.
Fix: Copy up the passthrough mount settings of the mark mount point to the
shiftfs overlay.
One solution would be to start reference counting which is overkill. We only
care about the passthrough mount option of the mark mount. And we only need it
to verify that on remount the new passthrough options of the shiftfs overlay
are a subset of the mark mount's passthrough options. In other scenarios we
don't care. So copying up is good enough and also only needs to happen once on
mount, i.e. when a new superblock is created and the .fill_super method is
called.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824735/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
