From nobody Fri Nov 22 16:41:30 2024 Received: from lichtman.org (lichtman.org [149.28.33.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6CF55762E0 for ; Fri, 15 Nov 2024 16:55:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=149.28.33.109 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731689743; cv=none; b=iKCGCB+7BkXAcoiZlxe2WwrMIoEgQ2lEJRMUFlnaQv8TPkd0IcAciNnFyFZn/LjrYgFE6rjl+tcpDWghBWKXD/x9LHTAf3jNrPv7DmJyzmMuDC/OJI/DJLhM7yfsDTCZZmtpjQEUSFltrwqMpeRQ1gc921pdvPLrdzlQV7fHmOA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731689743; c=relaxed/simple; bh=b7lGpWdm4rz58yr3GDepY+GoJDmX40WkokM3hkmIl6s=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=tFXzkVTGl0EOgeUv0TSMc5hQJ90VeRTlYV4cq1WzxAfwJatQ1v49jymmfbampFQl7CUYmxSGqEyLNsBpeNWOJv6gH1rXdI5z2NlGvpA6h9RGRm99IpuIxqjLwoXFaL+s4A0xPjmSOaVwddepSc/qF9DaVGw69vy0bvfkO25eX7o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lichtman.org; spf=pass smtp.mailfrom=lichtman.org; dkim=pass (2048-bit key) header.d=lichtman.org header.i=@lichtman.org header.b=qHYC794z; arc=none smtp.client-ip=149.28.33.109 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lichtman.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lichtman.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lichtman.org header.i=@lichtman.org header.b="qHYC794z" Received: by lichtman.org (Postfix, from userid 1000) id 876551770E5; Fri, 15 Nov 2024 16:55:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lichtman.org; s=mail; t=1731689741; bh=b7lGpWdm4rz58yr3GDepY+GoJDmX40WkokM3hkmIl6s=; h=Date:From:To:Subject:From; b=qHYC794z9fSe+3YxtW0slwOcoBY4AwWVOeHbySRA6BrbU5uLiUhObR0zVrDlRi59A es7I/ux5X92IAxgcbJmf625ODM9pD2jQh+82w3SpsGftzPVPpfwiqYkKZOH4vQqMvf pNWnlpOkLoanxzMTh52/G36x/k9dXRp0XkMgQApMrnBcKGLnnO0Xum3UbYrCW96m3l CwIl527Cm+rXW7xPnU7o+lQm/Dqz73cPzsUbelmMblLtI7obYvQVSBHhBZN7lYajh4 SDW8D+j530fyJCB2NPQzqajlqxWSnviXFHLekP/+h6aBwlJCDJXyj9uQSSY05Klvr8 XBaRc43Hx+uGQ== Date: Fri, 15 Nov 2024 16:55:41 +0000 From: Nir Lichtman To: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, ebiederm@xmission.com, kees@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] exec: fix no kernel module found error to be more clear Message-ID: <20241115165541.GB209124@lichtman.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Problem: Before starting the enumeration of the supported formats the default return value is set to no entity which is misleading since if the kernel module of the binary format is not found, it would return no entity to user mode which is misleading since it is signaling that a file was not found, but in this case the more suitable error is that the executable has an unsupported format Solution: Refactor to return no-exec error instead Signed-off-by: Nir Lichtman --- fs/exec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/exec.c b/fs/exec.c index 3394de5882af..6324f9546b09 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1740,7 +1740,7 @@ static int search_binary_handler(struct linux_binprm = *bprm) if (retval) return retval; =20 - retval =3D -ENOENT; + retval =3D -ENOEXEC; retry: read_lock(&binfmt_lock); list_for_each_entry(fmt, &formats, lh) { --=20 2.39.2