linux-kernel - [Bug] "WARNING in should_fail

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: <CAP=Rh=N4QcPLWQ2dqUHmKYeEhig3Cbi-3N8Q4-7qGT00htXrVw@mail.gmail.com>
Date: Wed, 21 May 2025 22:13:15 +0800
From: John <john.cs.hey@...il.com>
To: "David S. Miller" <davem@...emloft.net>, David Ahern <dsahern@...nel.org>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Cc: Simon Horman <horms@...nel.org>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [Bug] "WARNING in should_fail_ex" in Linux kernel v6.14

Dear Linux Kernel Maintainers,

I hope this message finds you well.

I am writing to report a potential vulnerability I encountered during
testing of the Linux Kernel version v6.14.

Git Commit: 38fec10eb60d687e30c8c6b5420d86e8149f7557 (tag: v6.14)

Bug Location: net/ipv4/ipmr.c:440 ipmr_free_table net/ipv4/ipmr.c:440

Bug report: https://pastebin.com/xkfF5DBt

Complete log: https://pastebin.com/uCfqY4D8

Entire kernel config: https://pastebin.com/MRWGr3nv

Root Cause Analysis:
The kernel warning is triggered in ipmr_free_table() at
net/ipv4/ipmr.c:440, where the multicast routing table (mr_table) is
being freed during network namespace exit (ipmr_rules_exit).
The warning indicates that the multicast forwarding cache count
(mfc_cache_cnt) is non-zero, implying that resources were not
correctly cleaned up prior to netns teardown.
This suggests a possible bug in reference counting or teardown logic
of the IPv4 multicast routing infrastructure.
Additionally, the environment is running with fail_usercopy fault
injection enabled, which deliberately triggers copy-from-user failures
to test kernel error paths.
While these failures are expected, they may interact with multicast
socket setup/teardown paths, exacerbating latent issues.

At present, I have not yet obtained a minimal reproducer for this
issue. However, I am actively working on reproducing it, and I will
promptly share any additional findings or a working reproducer as soon
as it becomes available.

Thank you very much for your time and attention to this matter. I
truly appreciate the efforts of the Linux kernel community.

Best regards,
John