Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752433AbdLUKiQ (ORCPT ); Thu, 21 Dec 2017 05:38:16 -0500 Received: from mail-qk0-f180.google.com ([209.85.220.180]:42730 "EHLO mail-qk0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751227AbdLUKiO (ORCPT ); Thu, 21 Dec 2017 05:38:14 -0500 X-Google-Smtp-Source: ACJfBou6aZRqTBpz4fATbcPtmNLlvEZTB4xEuo7K3Wy98lQgNh2kJk0IXjU//aXRqUzvgCnnH6yZ0nKeG8PuMS/Rcxg= MIME-Version: 1.0 In-Reply-To: <87po78trjm.fsf@xmission.com> References: <20171218221541.GP21978@ZenIV.linux.org.uk> <20171218231013.GA9481@codemonkey.org.uk> <20171219033926.GA26981@codemonkey.org.uk> <87lghy7eul.fsf@xmission.com> <20171219193020.GA9237@codemonkey.org.uk> <878tdy5r5t.fsf@xmission.com> <87mv2e17vz.fsf@xmission.com> <20171220052803.GA17079@codemonkey.org.uk> <871sjp1cjz.fsf@xmission.com> <20171221031606.GA4636@codemonkey.org.uk> <87po78trjm.fsf@xmission.com> From: Alexey Dobriyan Date: Thu, 21 Dec 2017 12:38:12 +0200 Message-ID: Subject: Re: proc_flush_task oops To: "Eric W. Biederman" Cc: Dave Jones , Linus Torvalds , Al Viro , Linux Kernel , syzkaller-bugs@googlegroups.com, Gargi Sharma , Oleg Nesterov , Rik van Riel , Andrew Morton Content-Type: multipart/mixed; boundary="001a114c895c1346620560d74c61" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2856 Lines: 57 --001a114c895c1346620560d74c61 Content-Type: text/plain; charset="UTF-8" On 12/21/17, Eric W. Biederman wrote: > I have stared at this code, and written some test programs and I can't > see what is going on. alloc_pid by design and in implementation (as far > as I can see) is always single threaded when allocating the first pid > in a pid namespace. idr_init always initialized idr_next to 0. > > So how we can get past: > > if (unlikely(is_child_reaper(pid))) { > if (pid_ns_prepare_proc(ns)) { > disable_pid_allocation(ns); > goto out_free; > } > } > > with proc_mnt still set to NULL is a mystery to me. > > Is there any chance the idr code doesn't always return the lowest valid > free number? So init gets assigned something other than 1? Well, this theory is easy to test (attached). There is a "valid" way to break the code via kernel.ns_last_pid: unshare+write+fork but the reproducer doesn't seem to use it (or it does?) --001a114c895c1346620560d74c61 Content-Type: text/plain; charset="US-ASCII"; name="pid1.diff" Content-Disposition: attachment; filename="pid1.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 ZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvcGlkX25hbWVzcGFjZS5oIGIvaW5jbHVkZS9saW51 eC9waWRfbmFtZXNwYWNlLmgKaW5kZXggNDk1MzhiMTcyNDgzLi45ODI5ZTc0YzliZDcgMTAwNjQ0 Ci0tLSBhL2luY2x1ZGUvbGludXgvcGlkX25hbWVzcGFjZS5oCisrKyBiL2luY2x1ZGUvbGludXgv cGlkX25hbWVzcGFjZS5oCkBAIC00NCw2ICs0NCw3IEBAIHN0cnVjdCBwaWRfbmFtZXNwYWNlIHsK IAlrZ2lkX3QgcGlkX2dpZDsKIAlpbnQgaGlkZV9waWQ7CiAJaW50IHJlYm9vdDsJLyogZ3JvdXAg ZXhpdCBjb2RlIGlmIHRoaXMgcGlkbnMgd2FzIHJlYm9vdGVkICovCisJYm9vbCBwaWQxOwogCXN0 cnVjdCBuc19jb21tb24gbnM7CiB9IF9fcmFuZG9taXplX2xheW91dDsKIApkaWZmIC0tZ2l0IGEv a2VybmVsL3BpZC5jIGIva2VybmVsL3BpZC5jCmluZGV4IGE3ZjM4YWZmNzQwYS4uYzJhZjRkNDIw ZTJhIDEwMDY0NAotLS0gYS9rZXJuZWwvcGlkLmMKKysrIGIva2VybmVsL3BpZC5jCkBAIC0xOTks NiArMTk5LDE1IEBAIHN0cnVjdCBwaWQgKmFsbG9jX3BpZChzdHJ1Y3QgcGlkX25hbWVzcGFjZSAq bnMpCiAJCQlnb3RvIG91dF9mcmVlOwogCQl9CiAKKworCQlpZiAobnMtPnBpZDEpIHsKKwkJCWlm IChuciAhPSAxKSB7CisJCQkJcHJpbnRrKCIlczogcGlkICVkXG4iLCBfX2Z1bmNfXywgbnIpOwor CQkJCUJVRygpOworCQkJfQorCQkJbnMtPnBpZDEgPSBmYWxzZTsKKwkJfQorCiAJCXBpZC0+bnVt YmVyc1tpXS5uciA9IG5yOwogCQlwaWQtPm51bWJlcnNbaV0ubnMgPSB0bXA7CiAJCXRtcCA9IHRt cC0+cGFyZW50OwpkaWZmIC0tZ2l0IGEva2VybmVsL3BpZF9uYW1lc3BhY2UuYyBiL2tlcm5lbC9w aWRfbmFtZXNwYWNlLmMKaW5kZXggMGI1M2VlZjdkMzRiLi4yMzRiZjdjMmQ1M2YgMTAwNjQ0Ci0t LSBhL2tlcm5lbC9waWRfbmFtZXNwYWNlLmMKKysrIGIva2VybmVsL3BpZF9uYW1lc3BhY2UuYwpA QCAtMTM1LDYgKzEzNSw3IEBAIHN0YXRpYyBzdHJ1Y3QgcGlkX25hbWVzcGFjZSAqY3JlYXRlX3Bp ZF9uYW1lc3BhY2Uoc3RydWN0IHVzZXJfbmFtZXNwYWNlICp1c2VyX25zCiAJbnMtPnVjb3VudHMg PSB1Y291bnRzOwogCW5zLT5waWRfYWxsb2NhdGVkID0gUElETlNfQURESU5HOwogCUlOSVRfV09S SygmbnMtPnByb2Nfd29yaywgcHJvY19jbGVhbnVwX3dvcmspOworCW5zLT5waWQxID0gdHJ1ZTsK IAogCXJldHVybiBuczsKIAo= --001a114c895c1346620560d74c61--