net: ipv6: flowlabel: defer exclusive option free until RCU teardown
Subsystems (4)
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/1 net: ipv6: flowlabel: defer exclusive option free until RCU teardown
From: Zhengchuan Liang <[email protected]>
ip6fl_seq_show() walks the global flowlabel hash under the seq-file RCU read-side lock and prints fl->opt->opt_nflen when an option block is present.
Exclusive flowlabels currently free fl->opt as soon as fl->users drops to zero in fl_release(). However, the surrounding struct ip6_flowlabel remains visible in the global hash table until later garbage collection removes it and fl_free_rcu() finally tears it down.
A concurrent /proc/net/ip6_flowlabel reader can therefore race that early kfree() and dereference freed option state, triggering a crash in ip6fl_seq_show().
Fix this by keeping fl->opt alive until fl_free_rcu(). That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.
--- net/ipv6/ip6_flowlabel.c | 5 ----- 1 file changed, 5 deletions(-)
net/ipv6/ip6_flowlabel.c +0 -5
@@ -133,11 +133,6 @@ static void fl_release(struct ip6_flowlabel *fl)if (time_after (ttd, fl->expires)) fl->expires = ttd; ttd = fl->expires; -if (fl->opt && fl->share ==IPV6_FL_S_EXCL ) { -struct ipv6_txoptions *opt = fl->opt; - fl->opt =NULL ; -kfree (opt); - }if (!timer_pending (&ip6_fl_gc_timer) ||time_after (ip6_fl_gc_timer.expires, ttd))mod_timer (&ip6_fl_gc_timer, ttd);
Signature · 1 line
2.43.0
Quoted 6 lines · Ren Wei
From: Zhengchuan Liang <[email protected]>
ip6fl_seq_show()walks the global flowlabel hash under the seq-file RCU read-side lock and printsfl->opt->opt_nflenwhen an option block is present.
Some points :
Please do not CC security@ if you submit a public patch, there is absolutely no reason for it.
Please do not resend the same version within 24 hours; this creates noise. Your patch wasn't lost; we have many patch reviews and similar bugs to address.
Thank you.
Quoted 8 lines · Eric Dumazet
Quoted 5 lines · Ren Wei
From: Zhengchuan Liang <[email protected]>
ip6fl_seq_show()walks the global flowlabel hash under the seq-file RCU read-side lock and printsfl->opt->opt_nflenwhen an option block is present.Some points :
Quoted 7 lines
Please do not CC security@ if you submit a public patch, there is absolutely no reason for it.
Please do not resend the same version within 24 hours; this creates noise. Your patch wasn't lost; we have many patch reviews and similar bugs to address.
Thank you.
We sincerely apologize for the confusion caused by our previous email. Previously, when we sent reports and patches to the security list, we were advised that patches should be submitted to netdev@ for public review. To follow this, we are now sending the full vulnerability details to security@ while additionally submitting the patches to netdev@. Please let us know if this is the correct way to handle such cases.
Regarding the CC list, could you provide further guidance on who we should include? Currently, we are CCing everyone suggested by get_maintainer.pl because we previously received feedback about missing relevant maintainers. For public mailing lists, we should only including netdev@. Should we be more selective?
Finally, regarding our tags, our team has a clear division of labor—some focus on finding vulnerabilities, others on fixing them, followed by an internal review and testing before a dedicated member handles community outreach.
We welcome any guidance and will improve our upcoming patches accordingly. To be honest, we are currently a bit uncertain about the exact workflow the community prefers, and we are eager to align our process with your expectations.
Quoted 14 lines · Yuan Tan
Quoted 11 lines · Eric Dumazet
Quoted 5 lines · Ren Wei
From: Zhengchuan Liang <[email protected]>
ip6fl_seq_show()walks the global flowlabel hash under the seq-file RCU read-side lock and printsfl->opt->opt_nflenwhen an option block is present.Some points :
Please do not CC security@ if you submit a public patch, there is absolutely no reason for it.
Quoted 6 lines
Quoted 4 lines
Please do not resend the same version within 24 hours; this creates noise. Your patch wasn't lost; we have many patch reviews and similar bugs to address.
Thank you.
We sincerely apologize for the confusion caused by our previous email. Previously, when we sent reports and patches to the security list, we were advised that patches should be submitted to netdev@ for public review. To follow this, we are now sending the full vulnerability details to security@ while additionally submitting the patches to netdev@. Please let us know if this is the correct way to handle such cases.
When/If an issue and a patch is sent publicly, security@ involvement ends. netdev maintainers take over.
Thus there is no point CCing this list of security officers, which is currently flooded by many LLM-based findings.
Please help them by keeping their inbox a bit saner.
Quoted 2 lines
Regarding the CC list, could you provide further guidance on who we should include? Currently, we are CCing everyone suggested by get_maintainer.pl because we previously received feedback about missing relevant maintainers. For public mailing lists, we should only including netdev@. Should we be more selective?
Yes, folks that are interesting into following netdev changes are subscribed to netdev@ mailing list.
Unless a patch touches non-networking parts and requires approval from other branch maintainers, there is no
point CCing other lists.
Quoted 3 lines
Finally, regarding our tags, our team has a clear division of labor—some focus on finding vulnerabilities, others on fixing them, followed by an internal review and testing before a dedicated member handles community outreach.
You included 8 tags, this seems a bit too much for such a small patch.
Quoted 2 lines
We welcome any guidance and will improve our upcoming patches accordingly. To be honest, we are currently a bit uncertain about the exact workflow the community prefers, and we are eager to align our process with your expectations.
Quoted 17 lines · Eric Dumazet
Quoted 16 lines · Yuan Tan
Quoted 14 lines · Eric Dumazet
Quoted 5 lines · Ren Wei
From: Zhengchuan Liang <[email protected]>
ip6fl_seq_show()walks the global flowlabel hash under the seq-file RCU read-side lock and printsfl->opt->opt_nflenwhen an option block is present.Some points :
Please do not CC security@ if you submit a public patch, there is absolutely no reason for it.
Please do not resend the same version within 24 hours; this creates noise. Your patch wasn't lost; we have many patch reviews and similar bugs to address.
Quoted 8 lines
Quoted 2 lines
Quoted 1 line
Thank you.
We sincerely apologize for the confusion caused by our previous email. Previously, when we sent reports and patches to the security list, we were advised that patches should be submitted to netdev@ for public review. To follow this, we are now sending the full vulnerability details to security@ while additionally submitting the patches to netdev@. Please let us know if this is the correct way to handle such cases.
When/If an issue and a patch is sent publicly, security@ involvement ends. netdev maintainers take over.
Thus there is no point CCing this list of security officers, which is currently flooded by many LLM-based findings.
Please help them by keeping their inbox a bit saner.
We would like to standardize our workflow to ensure it aligns with community expectations. We've checked the maillist and netdev docs for these details but found no clear answers. Could you please clarify which of the following is preferred?
Option 1: Send the security report to security@ and submit the patches directly to the subsystem mailing list without CC security@.
Option 2: Send both the report and the patches to security@ for an initial review. After approval, re-send the patches to the subsystem mailing list.
For Option 1, I have hread that there are bots on the public lists to help with the review. The Option 2 feels slightly redundant and might cause confusion. We are open to any other workflow that the community prefers.
We are wondering if it's better to send the PoC and detailed analysis directly to netdev@ for bugs we deem to have low exploitability, which would help minimize the burden on the security@ team. However, these bugs are still triggerable by unprivileged users, we are concerned that posting full PoC to a public mailing list might be inappropriate or risky.
Quoted 7 lines
Quoted 1 line
Regarding the CC list, could you provide further guidance on who we should include? Currently, we are CCing everyone suggested by get_maintainer.pl because we previously received feedback about missing relevant maintainers. For public mailing lists, we should only including netdev@. Should we be more selective?
Yes, folks that are interesting into following netdev changes are subscribed to netdev@ mailing list.
Unless a patch touches non-networking parts and requires approval from other branch maintainers, there is no
point CCing other lists.
Thank you for your advice. We will no longer CC individual maintainers on patches sent to netdev.
Regarding security reports, however, we had previously been advised to CC more people to avoid manual forwarding.
To be honest, we are a bit confused by the conflicting guidance we've received. We sincerely want to establish a standardized process for our future contributions to make everyone happy.
Quoted 3 lines
Quoted 2 lines
Finally, regarding our tags, our team has a clear division of labor—some focus on finding vulnerabilities, others on fixing them, followed by an internal review and testing before a dedicated member handles community outreach.
You included 8 tags, this seems a bit too much for such a small patch.
CC Greg here, as he knows a bit about our team's background.
Our team has developed a tool that found hundreds of non-root bugs with PoCs. We want to ensure these are fixed properly and quickly rather than dumping reports onto the mailing list and hoping for others to find the time to fix. So we have organized a group of promising students. As some of them are new to kernel development, we have been providing hands-on mentorship to guide them through the process.
Regarding credit attribution: Yuan, Yifan, Jufei, and Xin were all instrumental in the tool's design and implementation, so we listed them with Reported-by tags. Xin provided the funding and led the fixing team, so we included a Suggested-by tag for him (though this could be changed to Reported-by as well). Then after including the patch author, this naturally results in five tags.
As for using a designated sender to submit these patches, it's because using Gmail with git send-email is difficult in China and the university email servers prohibit the use of the SMTP protocol. Therefore, we had to apply for a separate account specifically with SMTP permissions to submit patches.
We fully respect the maintainers' discretion in this matter. If the current tags are still considered unacceptable, we will make the necessary internal adjustments.
Quoted 2 lines
Quoted 2 lines
We welcome any guidance and will improve our upcoming patches accordingly. To be honest, we are currently a bit uncertain about the exact workflow the community prefers, and we are eager to align our process with your expectations.
Quoted 10 lines · Yuan Tan
Quoted 8 lines · Eric Dumazet
Quoted 6 lines · Yuan Tan
On 3/31/2026 1:52 AM, Eric Dumazet wrote:
Finally, regarding our tags, our team has a clear division of labor—some focus on finding vulnerabilities, others on fixing them, followed by an internal review and testing before a dedicated member handles community outreach.You included 8 tags, this seems a bit too much for such a small patch.
CC Greg here, as he knows a bit about our team's background.
Yeah, 8 tags "seems" like a lot, but for a team that is working on these things, I think that is good, a bunch of people are wanting to be on the "path of blame if something went wrong" which is nice to see, they aren't just dumping the responsibility onto one person :)
So I don't have any objection to this at all, and in fact, welcome it.
Quoted 6 lines
Our team has developed a tool that found hundreds of non-root bugs with PoCs. We want to ensure these are fixed properly and quickly rather than dumping reports onto the mailing list and hoping for others to find the time to fix. So we have organized a group of promising students. As some of them are new to kernel development, we have been providing hands-on mentorship to guide them through the process.
This is a good thing, thanks for doing this, it is helping both the kernel out in getting these things fixed, and these students to get them great experience in working upstream in a proper way.
This is great stuff, I wish more professors and schools would do this.
thanks,
greg k-h
Quoted 91 lines · Yuan Tan
Quoted 17 lines · Eric Dumazet
Quoted 16 lines · Yuan Tan
Quoted 14 lines · Eric Dumazet
Quoted 5 lines · Ren Wei
From: Zhengchuan Liang <[email protected]>
ip6fl_seq_show()walks the global flowlabel hash under the seq-file RCU read-side lock and printsfl->opt->opt_nflenwhen an option block is present.Some points :
Please do not CC security@ if you submit a public patch, there is absolutely no reason for it.
Please do not resend the same version within 24 hours; this creates noise. Your patch wasn't lost; we have many patch reviews and similar bugs to address.
Quoted 8 lines
Quoted 2 lines
Quoted 1 line
Thank you.
We sincerely apologize for the confusion caused by our previous email. Previously, when we sent reports and patches to the security list, we were advised that patches should be submitted to netdev@ for public review. To follow this, we are now sending the full vulnerability details to security@ while additionally submitting the patches to netdev@. Please let us know if this is the correct way to handle such cases.
When/If an issue and a patch is sent publicly, security@ involvement ends. netdev maintainers take over.
Thus there is no point CCing this list of security officers, which is currently flooded by many LLM-based findings.
Please help them by keeping their inbox a bit saner.We would like to standardize our workflow to ensure it aligns with community expectations. We've checked the maillist and netdev docs for these details but found no clear answers. Could you please clarify which of the following is preferred?
Option 1: Send the security report to security@ and submit the patches directly to the subsystem mailing list without CC security@.
Option 2: Send both the report and the patches to security@ for an initial review. After approval, re-send the patches to the subsystem mailing list.
For Option 1, I have hread that there are bots on the public lists to help with the review. The Option 2 feels slightly redundant and might cause confusion. We are open to any other workflow that the community prefers.
We are wondering if it's better to send the PoC and detailed analysis directly to netdev@ for bugs we deem to have low exploitability, which would help minimize the burden on the security@ team. However, these bugs are still triggerable by unprivileged users, we are concerned that posting full PoC to a public mailing list might be inappropriate or risky.
Quoted 7 lines
Quoted 1 line
Regarding the CC list, could you provide further guidance on who we should include? Currently, we are CCing everyone suggested by get_maintainer.pl because we previously received feedback about missing relevant maintainers. For public mailing lists, we should only including netdev@. Should we be more selective?
Yes, folks that are interesting into following netdev changes are subscribed to netdev@ mailing list.
Unless a patch touches non-networking parts and requires approval from other branch maintainers, there is no
point CCing other lists.Thank you for your advice. We will no longer CC individual maintainers on patches sent to netdev.
Regarding security reports, however, we had previously been advised to CC more people to avoid manual forwarding.
To be honest, we are a bit confused by the conflicting guidance we've received. We sincerely want to establish a standardized process for our future contributions to make everyone happy.
Quoted 3 lines
Quoted 2 lines
Finally, regarding our tags, our team has a clear division of labor—some focus on finding vulnerabilities, others on fixing them, followed by an internal review and testing before a dedicated member handles community outreach.
You included 8 tags, this seems a bit too much for such a small patch.
CC Greg here, as he knows a bit about our team's background.
Our team has developed a tool that found hundreds of non-root bugs with PoCs. We want to ensure these are fixed properly and quickly rather than dumping reports onto the mailing list and hoping for others to find the time to fix. So we have organized a group of promising students. As some of them are new to kernel development, we have been providing hands-on mentorship to guide them through the process.
Regarding credit attribution: Yuan, Yifan, Jufei, and Xin were all instrumental in the tool's design and implementation, so we listed them with Reported-by tags. Xin provided the funding and led the fixing team, so we included a Suggested-by tag for him (though this could be changed to Reported-by as well). Then after including the patch author, this naturally results in five tags.
As for using a designated sender to submit these patches, it's because using Gmail with git send-email is difficult in China and the university email servers prohibit the use of the SMTP protocol. Therefore, we had to apply for a separate account specifically with SMTP permissions to submit patches.
Quoted 3 lines
We fully respect the maintainers' discretion in this matter. If the current tags are still considered unacceptable, we will make the necessary internal adjustments.
Again, no need for all this, I already gave a 'Reviewed-by', I was not saying it was unaccptable.
Oh well.
Quoted 21 lines · Ren Wei
From: Zhengchuan Liang <[email protected]>
ip6fl_seq_show()walks the global flowlabel hash under the seq-file RCU read-side lock and printsfl->opt->opt_nflenwhen an option block is present.Exclusive flowlabels currently free
fl->optas soon asfl->usersdrops to zero infl_release(). However, the surroundingstruct ip6_flowlabelremains visible in the global hash table until later garbage collection removes it andfl_free_rcu()finally tears it down.A concurrent
/proc/net/ip6_flowlabelreader can therefore race that earlykfree()and dereference freed option state, triggering a crash inip6fl_seq_show().Fix this by keeping
fl->optalive untilfl_free_rcu(). That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.
Quoted 9 lines
Fixes d3aedd5ebd4b ("ipv6 flowlabel: Convert hash list to RCU.")Reported-by Yifan Wu <[email protected]>Reported-by Juefei Pu <[email protected]>Co-developed-by Yuan Tan <[email protected]>Signed-off-by Yuan Tan <[email protected]>Suggested-by Xin Liu <[email protected]>Tested-by Ren Wei <[email protected]>Signed-off-by Zhengchuan Liang <[email protected]>Signed-off-by Ren Wei <[email protected]>
Quite a long and confusing list of tags, and a long CC list ...
Please trim this next time you submit a networking patch.
This patch was applied to netdev/net.git (main) by Jakub Kicinski <[email protected]>:
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <[email protected]>:
Quoted 6 lines · On Mon, 30 Mar 2026 16:46:24 +0800 you wrote:
From: Zhengchuan Liang <[email protected]>
ip6fl_seq_show()walks the global flowlabel hash under the seq-file RCU read-side lock and printsfl->opt->opt_nflenwhen an option block is present.
Quoted 7 lines
Exclusive flowlabels currently free
fl->optas soon asfl->usersdrops to zero infl_release(). However, the surroundingstruct ip6_flowlabelremains visible in the global hash table until later garbage collection removes it andfl_free_rcu()finally tears it down.[...]
Here is the summary with links:
- [1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown
https://git.kernel.org/netdev/net/c/9ca562bb8e66
You are awesome, thank you!
Signature · 2 lines
Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html