pnode: terminate at peers of source

In the Linux kernel, the following vulnerability has been resolved:

pnode: terminate at peers of source

The propagate_mnt() function handles mount propagation when creating

mounts and propagates the source mount tree @source_mnt to all

applicable nodes of the destination propagation mount tree headed by

@dest_mnt.

Unfortunately it contains a bug where it fails to terminate at peers of

@source_mnt when looking up copies of the source mount that become

masters for copies of the source mount tree mounted on top of slaves in

the destination propagation tree causing a NULL dereference.

Once the mechanics of the bug are understood it's easy to trigger.

Because of unprivileged user namespaces it is available to unprivileged

users.

While fixing this bug we've gotten confused multiple times due to

unclear terminology or missing concepts. So let's start this with some

clarifications:

* The terms "master" or "peer" denote a shared mount. A shared mount

belongs to a peer group.

* A peer group is a set of shared mounts that propagate to each other.

They are identified by a peer group id. The peer group id is available

in @shared_mnt->mnt_group_id.

Shared mounts within the same peer group have the same peer group id.

The peers in a peer group can be reached via @shared_mnt->mnt_share.

* The terms "slave mount" or "dependent mount" denote a mount that

receives propagation from a peer in a peer group. IOW, shared mounts

may have slave mounts and slave mounts have shared mounts as their

master. Slave mounts of a given peer in a peer group are listed on

that peers slave list available at @shared_mnt->mnt_slave_list.

* The term "master mount" denotes a mount in a peer group. IOW, it

denotes a shared mount or a peer mount in a peer group. The term

"master mount" - or "master" for short - is mostly used when talking

in the context of slave mounts that receive propagation from a master

mount. A master mount of a slave identifies the closest peer group a

slave mount receives propagation from. The master mount of a slave can

be identified via @slave_mount->mnt_master. Different slaves may point

to different masters in the same peer group.

* Multiple peers in a peer group can have non-empty ->mnt_slave_lists.

Non-empty ->mnt_slave_lists of peers don't intersect. Consequently, to

ensure all slave mounts of a peer group are visited the

->mnt_slave_lists of all peers in a peer group have to be walked.

* Slave mounts point to a peer in the closest peer group they receive

propagation from via @slave_mnt->mnt_master (see above). Together with

these peers they form a propagation group (see below). The closest

peer group can thus be identified through the peer group id

@slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave

mount receives propagation from.

* A shared-slave mount is a slave mount to a peer group pg1 while also

a peer in another peer group pg2. IOW, a peer group may receive

propagation from another peer group.

If a peer group pg1 is a slave to another peer group pg2 then all

peers in peer group pg1 point to the same peer in peer group pg2 via

->mnt_master. IOW, all peers in peer group pg1 appear on the same

->mnt_slave_list. IOW, they cannot be slaves to different peer groups.

* A pure slave mount is a slave mount that is a slave to a peer group

but is not a peer in another peer group.

* A propagation group denotes the set of mounts consisting of a single

peer group pg1 and all slave mounts and shared-slave mounts that point

to a peer in that peer group via ->mnt_master. IOW, all slave mounts

such that @slave_mnt->mnt_master->mnt_group_id is equal to

@shared_mnt->mnt_group_id.

The concept of a propagation group makes it easier to talk about a

single propagation level in a propagation tree.

For example, in propagate_mnt() the immediate peers of @dest_mnt and

all slaves of @dest_mnt's peer group form a propagation group pr

---truncated---