When xfrm_policy_insert() fails, the error path performs manual
cleanup by calling xfrm_dev_policy_free(), security_xfrm_policy_free()
and kfree() directly. This is incorrect because xfrm_policy_destroy()
already handles all of these, causing a memory leak detected by
kmemleak.

Replace the open-coded cleanup with xfrm_policy_destroy(), consistent
with the error handling in xfrm_policy_construct(). The walk.dead
flag must be set before calling xfrm_policy_destroy() as it requires
it via BUG_ON(!policy->walk.dead).

Fixes: 94b95dfaa814 ("xfrm: release all offloaded policy memory")
Reported-by: syzbot+901d48e0b95aed4a2548@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=901d48e0b95aed4a2548
Tested-by: syzbot+901d48e0b95aed4a2548@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 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

2026-04-12, 07:38:09 +0530, Deepanshu Kartikey wrote:
> When xfrm_policy_insert() fails, the error path performs manual
> cleanup by calling xfrm_dev_policy_free(), security_xfrm_policy_free()
> and kfree() directly. This is incorrect because xfrm_policy_destroy()
> already handles all of these, causing a memory leak detected by
> kmemleak.

What is missing in the current code? "we have a better way to do this"
is not a bugfix, it's a clean up. The kmemleak report says that we're
leaking the xfrm_policy struct on this codepath, which doesn't make
sense, that's covered by the existing kfree(xp).

Also, please use "PATCH ipsec" for fixes to net/xfrm and the rest of
the IPsec implementation.

-- 
Sabrina

On Mon, Apr 13, 2026 at 7:03 PM Sabrina Dubroca <sd@queasysnail.net> wrote:
>

> What is missing in the current code? "we have a better way to do this"
> is not a bugfix, it's a clean up. The kmemleak report says that we're
> leaking the xfrm_policy struct on this codepath, which doesn't make
> sense, that's covered by the existing kfree(xp).
>
> Also, please use "PATCH ipsec" for fixes to net/xfrm and the rest of
> the IPsec implementation.
>
> --
> Sabrina

Hi Sabrina,

Thanks for the review!

You are right, the existing kfree(xp) already covers the struct
itself, so my commit message was incorrect in claiming a memory
leak fix. I will resend this as a cleanup patch to replace the
open-coded manual cleanup with xfrm_policy_destroy(), which is
more consistent with xfrm_policy_construct() error handling.

I am also separately investigating the root cause of the actual
kmemleak report and will send a proper fix once identified.

Sorry for the noise and thanks again for the guidance.

Deepanshu

2026-04-13, 19:58:53 +0530, Deepanshu Kartikey wrote:
> On Mon, Apr 13, 2026 at 7:03 PM Sabrina Dubroca <sd@queasysnail.net> wrote:
> >
> 
> > What is missing in the current code? "we have a better way to do this"
> > is not a bugfix, it's a clean up. The kmemleak report says that we're
> > leaking the xfrm_policy struct on this codepath, which doesn't make
> > sense, that's covered by the existing kfree(xp).
> >
> > Also, please use "PATCH ipsec" for fixes to net/xfrm and the rest of
> > the IPsec implementation.
> >
> > --
> > Sabrina
> 
> Hi Sabrina,
> 
> Thanks for the review!
> 
> You are right, the existing kfree(xp) already covers the struct
> itself, so my commit message was incorrect in claiming a memory
> leak fix. I will resend this as a cleanup patch to replace the
> open-coded manual cleanup with xfrm_policy_destroy(), which is
> more consistent with xfrm_policy_construct() error handling.

Ok. Then you should wait 2 weeks until the merge window is over:
https://lore.kernel.org/netdev/20260412142250.131bf997@kernel.org/

and use "[PATCH ipsec-next]" as prefix for the cleanup patch (+ drop
the syzbot references).

> I am also separately investigating the root cause of the actual
> kmemleak report and will send a proper fix once identified.

Ok, thanks.

-- 
Sabrina

On Mon, Apr 13, 2026 at 8:04 PM Sabrina Dubroca <sd@queasysnail.net> wrote:
>
> Ok. Then you should wait 2 weeks until the merge window is over:
> https://lore.kernel.org/netdev/20260412142250.131bf997@kernel.org/
>
> and use "[PATCH ipsec-next]" as prefix for the cleanup patch (+ drop
> the syzbot references).
>

Hi Sabrina,

Thanks for the guidance.  I have submitted patch v3.

Thanks

Deepanshu