netdev - Re: CVE-2021-47285: net/nfc/rawsock.c: fix a permission check bug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4bka5bbczovc7z3tplqjlsfukf6qneg4wwddixgodsgqkudwlu@yws3uczmtzsn>
Date: Tue, 2 Jul 2024 18:15:09 +0200
From: Michal Koutný <mkoutny@...e.com>
To: cve@...nel.org, linux-kernel@...r.kernel.org
Cc: linux-cve-announce@...r.kernel.org, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, netdev@...r.kernel.org
Subject: Re: CVE-2021-47285: net/nfc/rawsock.c: fix a permission check bug

Hello.

On Tue, May 21, 2024 at 04:20:39PM GMT, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> In the Linux kernel, the following vulnerability has been resolved:
> 
> net/nfc/rawsock.c: fix a permission check bug
> 
> The function rawsock_create() calls a privileged function sk_alloc(), which requires a ns-aware check to check net->user_ns, i.e., ns_capable(). However, the original code checks the init_user_ns using capable(). So we replace the capable() with ns_capable().
> 
> The Linux kernel CVE team has assigned CVE-2021-47285 to this issue.
> ...
> 	https://git.kernel.org/stable/c/8ab78863e9eff11910e1ac8bcf478060c29b379e

Despite the patch changes guard related to EPERM bailout, it actually
swaps a "stronger" predicate capable() for a "weaker" ns_capable().

Without the patch, an unprivilged user is not allowed to create nfc
SOCK_RAW inside owned netns, with the patch, it's allowed.

That's a functional change but not security related. Or have I missed a
negation somewhere?

Thanks,
Michal

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)