[PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown

[PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown

[Ren Wei]

From: Zhengchuan Liang <zcliangcn@gmail.com>

`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.

Fixes: d3aedd5ebd4b ("ipv6 flowlabel: Convert hash list to RCU.")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Ren Wei <enjou1224z@gmail.com>
Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
 net/ipv6/ip6_flowlabel.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 7c12bf75beedf..c92f98c6f6ecc 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -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);
-- 
2.43.0

[PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown

[Ren Wei]

From: Zhengchuan Liang <zcliangcn@gmail.com>

`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.

Fixes: d3aedd5ebd4b ("ipv6 flowlabel: Convert hash list to RCU.")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Ren Wei <enjou1224z@gmail.com>
Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
 net/ipv6/ip6_flowlabel.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 7c12bf75beedf..c92f98c6f6ecc 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -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);
-- 
2.43.0

Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown

[Eric Dumazet]

On Tue, Mar 31, 2026 at 1:34 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
>
> From: Zhengchuan Liang <zcliangcn@gmail.com>
>
> `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.

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.

Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown

[Eric Dumazet]

On Mon, Mar 30, 2026 at 1:52 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
>
> From: Zhengchuan Liang <zcliangcn@gmail.com>
>
> `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.
>
> Fixes: d3aedd5ebd4b ("ipv6 flowlabel: Convert hash list to RCU.")
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> Tested-by: Ren Wei <enjou1224z@gmail.com>
> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>

Quite a long and confusing list of tags, and a long CC list ...

Please trim this next time you submit a networking patch.

Reviewed-by: Eric Dumazet <edumazet@google.com>

Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown

[Yuan Tan]

On 3/31/2026 1:52 AM, Eric Dumazet wrote:
> On Tue, Mar 31, 2026 at 1:34 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
>> From: Zhengchuan Liang <zcliangcn@gmail.com>
>>
>> `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.
> 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.

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.

Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown

[Eric Dumazet]

On Tue, Mar 31, 2026 at 5:41 PM Yuan Tan <yuantan098@gmail.com> wrote:
>
>
> On 3/31/2026 1:52 AM, Eric Dumazet wrote:
> > On Tue, Mar 31, 2026 at 1:34 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
> >> From: Zhengchuan Liang <zcliangcn@gmail.com>
> >>
> >> `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.
> > 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.
>
> 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.

>
> 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.

>
> 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.

> 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.
>

Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Mon, 30 Mar 2026 16:46:24 +0800 you wrote:
> From: Zhengchuan Liang <zcliangcn@gmail.com>
> 
> `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.
> 
> [...]

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!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown

[Yuan Tan]

On 3/31/2026 6:05 PM, Eric Dumazet wrote:
> On Tue, Mar 31, 2026 at 5:41 PM Yuan Tan <yuantan098@gmail.com> wrote:
>>
>> On 3/31/2026 1:52 AM, Eric Dumazet wrote:
>>> On Tue, Mar 31, 2026 at 1:34 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
>>>> From: Zhengchuan Liang <zcliangcn@gmail.com>
>>>>
>>>> `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.
>>> 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.
>> 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.
>> 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.

>> 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.

>> 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.
>>

Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown

[Greg KH]

On Wed, Apr 01, 2026 at 12:05:31AM -0700, Yuan Tan wrote:
> On 3/31/2026 6:05 PM, Eric Dumazet wrote:
> > On Tue, Mar 31, 2026 at 5:41 PM Yuan Tan <yuantan098@gmail.com> wrote:
> >> 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.

> 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

Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown

[Eric Dumazet]

On Wed, Apr 1, 2026 at 12:05 AM Yuan Tan <yuantan098@gmail.com> wrote:
>
>
> On 3/31/2026 6:05 PM, Eric Dumazet wrote:
> > On Tue, Mar 31, 2026 at 5:41 PM Yuan Tan <yuantan098@gmail.com> wrote:
> >>
> >> On 3/31/2026 1:52 AM, Eric Dumazet wrote:
> >>> On Tue, Mar 31, 2026 at 1:34 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
> >>>> From: Zhengchuan Liang <zcliangcn@gmail.com>
> >>>>
> >>>> `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.
> >>> 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.
> >> 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.
> >> 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.
>
> >> 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.

Again, no need for all this, I already gave a 'Reviewed-by', I was not
saying it was unaccptable.

Oh well.