From: Alexei Starovoitov <alexei.starovoitov@gmail.com> To: Roman Gushchin <guro@fb.com> Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, linux-kernel@vger.kernel.org, kernel-team@fb.com, netdev@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH bpf] bpf: cgroup: prevent out-of-order release of cgroup bpf Date: Fri, 3 Jan 2020 16:35:25 -0800 Message-ID: <20200104003523.rfte5rw6hbnncjes@ast-mbp> (raw) In-Reply-To: <20191227215034.3169624-1-guro@fb.com> On Fri, Dec 27, 2019 at 01:50:34PM -0800, Roman Gushchin wrote: > Before commit 4bfc0bb2c60e ("bpf: decouple the lifetime of cgroup_bpf > from cgroup itself") cgroup bpf structures were released with > corresponding cgroup structures. It guaranteed the hierarchical order > of destruction: children were always first. It preserved attached > programs from being released before their propagated copies. > > But with cgroup auto-detachment there are no such guarantees anymore: > cgroup bpf is released as soon as the cgroup is offline and there are > no live associated sockets. It means that an attached program can be > detached and released, while its propagated copy is still living > in the cgroup subtree. This will obviously lead to an use-after-free > bug. ... > @@ -65,6 +65,9 @@ static void cgroup_bpf_release(struct work_struct *work) > > mutex_unlock(&cgroup_mutex); > > + for (p = cgroup_parent(cgrp); p; p = cgroup_parent(p)) > + cgroup_bpf_put(p); > + The fix makes sense, but is it really safe to walk cgroup hierarchy without holding cgroup_mutex?
next prev parent reply index Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-27 21:50 Roman Gushchin 2020-01-03 15:30 ` Roman Gushchin 2020-01-03 17:47 ` Song Liu 2020-01-04 0:35 ` Alexei Starovoitov [this message] 2020-01-04 1:13 ` Roman Gushchin 2020-01-04 2:31 ` Alexei Starovoitov 2020-01-04 3:00 ` Roman Gushchin 2020-01-06 22:07 ` Alexei Starovoitov 2020-01-06 22:20 ` Roman Gushchin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200104003523.rfte5rw6hbnncjes@ast-mbp \ --to=alexei.starovoitov@gmail.com \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=daniel@iogearbox.net \ --cc=guro@fb.com \ --cc=kernel-team@fb.com \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=stable@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
BPF Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \ bpf@vger.kernel.org public-inbox-index bpf Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.bpf AGPL code for this site: git clone https://public-inbox.org/public-inbox.git