From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id BCEB994318 for ; Wed, 10 Apr 2024 14:17:07 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A6340F33C for ; Wed, 10 Apr 2024 14:17:07 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Wed, 10 Apr 2024 14:17:06 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 6ABE443AF9 for ; Wed, 10 Apr 2024 14:17:06 +0200 (CEST) From: Wolfgang Bumiller To: pve-devel@lists.proxmox.com Date: Wed, 10 Apr 2024 14:17:05 +0200 Message-Id: <20240410121705.6620-1-w.bumiller@proxmox.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.086 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: [pve-devel] [PATCH kernel] add apparmor patch to fix recvmsg returning EINVAL X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2024 12:17:07 -0000 With apparmor 4, when recvmsg() calls are checked by the apparmor LSM they will always return EINVAL. This causes very weird issues when apparmor profiles are in use, and a lot of networking issues in containers (which are always using apparmor). When coming from sys_recvmsg, msg->msg_namelen is explicitly set to zero early on. (see ____sys_recvmsg in net/socket.c) We still end up in 'map_addr' where the assumption is that addr != NULL means addrlen has a valid size. This is likely not a final fix, it was suggested by jjohansen on irc to get things going until this is resolved properly. Signed-off-by: Wolfgang Bumiller --- ...pect-msg_namelen-0-for-recvmsg-calls.patch | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 patches/kernel/0012-apparmor-expect-msg_namelen-0-for-recvmsg-calls.patch diff --git a/patches/kernel/0012-apparmor-expect-msg_namelen-0-for-recvmsg-calls.patch b/patches/kernel/0012-apparmor-expect-msg_namelen-0-for-recvmsg-calls.patch new file mode 100644 index 0000000..c68c191 --- /dev/null +++ b/patches/kernel/0012-apparmor-expect-msg_namelen-0-for-recvmsg-calls.patch @@ -0,0 +1,31 @@ +From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 +From: Wolfgang Bumiller +Date: Wed, 10 Apr 2024 13:21:59 +0200 +Subject: [PATCH] apparmor: expect msg_namelen=0 for recvmsg calls + +When coming from sys_recvmsg, msg->msg_namelen is explicitly set to +zero early on. (see ____sys_recvmsg in net/socket.c) +We still end up in 'map_addr' where the assumption is that addr != +NULL means addrlen has a valid size. + +This is likely not a final fix, it was suggested by jjohansen on irc +to get things going until this is resolved properly. + +Signed-off-by: Wolfgang Bumiller +--- + security/apparmor/af_inet.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/security/apparmor/af_inet.c b/security/apparmor/af_inet.c +index fb5cd985630d..6a056e1c30d6 100644 +--- a/security/apparmor/af_inet.c ++++ b/security/apparmor/af_inet.c +@@ -768,7 +768,7 @@ int aa_inet_msg_perm(const char *op, u32 request, struct socket *sock, + /* do we need early bailout for !family ... */ + return sk_has_perm2(sock->sk, op, request, profile, ad, + map_sock_addr(sock, ADDR_LOCAL, &laddr, &ad), +- map_addr(msg->msg_name, msg->msg_namelen, 0, ++ map_addr(msg->msg_namelen == 0 ? NULL : msg->msg_name, msg->msg_namelen, 0, + ADDR_REMOTE, &raddr, &ad), + profile_remote_perm(profile, sock->sk, request, + &raddr, &laddr.maddr, &ad)); -- 2.39.2