From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f70.google.com (mail-ot1-f70.google.com [209.85.210.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 95727239E75 for ; Sun, 12 Apr 2026 00:23:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775953414; cv=none; b=D5+L2eS01kOd5qaBqObybdTEsJhb2C4GFdW+IVbU2Zde7EY2d9+a3XoPK/h+pBTSnD49eVHnVjnvQa2Uo5aGC3I47k1sSlBzc2wbNpjOLQwq3Brgr0s0vJJHd81Sk86itB7knMYFpnDxjyuiGOdRmUSBHo3jDRgf/lQmOpBPRIo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775953414; c=relaxed/simple; bh=C3/bcau5+pDIlzRADMU8GjqUdZvHiTp74fOoRrb9w60=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=p9/wzObGVxXgYbKb3pbBc6gPzjVY84G/yoG2Y5BImjbysDy/cblvs6XPDpjEIXlSxv+RZCOYyswmIcTHnvH7NHr7j3/xaOCTtpB1rpiygsmocDdlkhYWgExv+XggxzfmZBJIliVnkH9cUfakDP7PO/Xgp5iUmp0d5zdOhBdXqEs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.210.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-ot1-f70.google.com with SMTP id 46e09a7af769-7dc4bfa79aaso20922a34.3 for ; Sat, 11 Apr 2026 17:23:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775953411; x=1776558211; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6VEn7DBPPcgs2W+pI34H474jewgrNQ9LF6UOHdxe9es=; b=QPissuzXa6nHE34Ea+Nmq6n3rzbLhwCWx9fL6r7EwC/xv+bwCfgfegCtgnEIYbtwyX 8PeX62Zd8NR0Y8JF6WFHpkeZLioXb2Pu9lA/GFSjP9b0FwI0EwZODbIQbtFxiMUzg12G E43t+r7Nap2kZLJZuKJxEF1k8O48BpZLYiLBrzzsKKQ+rZUTC81nbhTcJkD0oR7H6x6C u8As/vlJGMSe+aBtb+Oz39ujWRsehujkYMeD3X9qwraPWg7OKCyLgLER57qpasDoOAcc DRINTRGLMLiOoEeAnS6oDdelAYXPL6q0Buco6Afz2HMYQICIG62tek0EaqSuU8rlXCuf tazg== X-Gm-Message-State: AOJu0Yy4ds4i/KEEPRVKnfcE6u44VTWJ6iOwziGs9toBZsTNZ8S0C6Th C6ydMNHO8D3DuP1jtN3kiTpl/cf9rJHWHaCAV2A5aCoi1XmYNdfRvpHVHcGROAuSCn7ihtXBqUL s4hZWXem7VEzaE3YoQLJnatry4qBT4TqYmdxZeHvx+ktGgA4JL2iyYakl1Lg= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6820:82c:b0:68e:3db1:bdb9 with SMTP id 006d021491bc7-68e3db1be70mr1177933eaf.22.1775953411564; Sat, 11 Apr 2026 17:23:31 -0700 (PDT) Date: Sat, 11 Apr 2026 17:23:31 -0700 In-Reply-To: <69d678c4.050a0220.3030df.000a.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <69dae603.a00a0220.475f0.000d.GAE@google.com> Subject: Forwarded: [PATCH] xfrm: fix memory leak and improper cleanup in xfrm_add_policy() From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" For archival purposes, forwarding an incoming command email to linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com. *** Subject: [PATCH] xfrm: fix memory leak and improper cleanup in xfrm_add_policy() Author: kartikey406@gmail.com #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master When xfrm_policy_insert() fails in xfrm_add_policy(), the error handling path manually calls xfrm_dev_policy_free(), followed by security_xfrm_policy_free() and a raw kfree(). This is problematic for three reasons: 1. xfrm_policy_destroy() already calls xfrm_dev_policy_free() internally, so the manual call results in a double-free. 2. xfrm_policy_destroy() frees the policy asynchronously via call_rcu(), which schedules xfrm_policy_destroy_rcu() to call security_xfrm_policy_free() and kfree(). The manual security_xfrm_policy_free() call before kfree() races with this RCU callback, causing another double-free. 3. The raw kfree() is not RCU-safe and may free memory that is still being accessed by concurrent RCU readers. Fix this by using xfrm_policy_destroy() as the single, correct cleanup path, consistent with how xfrm_policy_construct() handles its own error paths. The walk.dead flag must be set first as xfrm_policy_destroy() requires it via BUG_ON(!policy->walk.dead). Reported-by: syzbot+901d48e0b95aed4a2548@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=901d48e0b95aed4a2548 Signed-off-by: Deepanshu Kartikey --- net/xfrm/xfrm_user.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c index d56450f61669..ae144d1e4a65 100644 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -2267,9 +2267,8 @@ static int xfrm_add_policy(struct sk_buff *skb, struct nlmsghdr *nlh, if (err) { xfrm_dev_policy_delete(xp); - xfrm_dev_policy_free(xp); - security_xfrm_policy_free(xp->security); - kfree(xp); + xp->walk.dead = 1; + xfrm_policy_destroy(xp); return err; } -- 2.43.0