[PATCH v2 0/2] net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak

[PATCH v2 0/2] net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak

[Ranganath V N]

Fix a KMSAN kernel-infoleak detected  by the syzbot .

[net?] KMSAN: kernel-infoleak in __skb_datagram_iter

In tcf_ife_dump(), the variable 'opt' was partially initialized using a
designatied initializer. While the padding bytes are reamined
uninitialized. nla_put() copies the entire structure into a
netlink message, these uninitialized bytes leaked to userspace.

Initialize the structure with memset before assigning its fields
to ensure all members and padding are cleared prior to beign copied.

Signed-off-by: Ranganath V N <vnranganath.20@gmail.com>
---
Changes in v2:
- removed memset(&t, 0, sizeof(t)) from previous patch.
- added the new patch series to address the issue.
- Link to v1: https://lore.kernel.org/r/20251031-infoleak-v1-1-9f7250ee33aa@gmail.com

---
Ranganath V N (2):
      net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak
      net: sched: act_connmark: zero initialize the struct to avoid KMSAN

 net/sched/act_connmark.c | 12 +++++++-----
 net/sched/act_ife.c      | 12 +++++++-----
 2 files changed, 14 insertions(+), 10 deletions(-)
---
base-commit: d127176862a93c4b3216bda533d2bee170af5e71
change-id: 20251031-infoleak-8a7de6afc987

Best regards,
-- 
Ranganath V N <vnranganath.20@gmail.com>

[PATCH v2 1/2] net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak

[Ranganath V N]

Fix a KMSAN kernel-infoleak detected  by the syzbot .

[net?] KMSAN: kernel-infoleak in __skb_datagram_iter

In tcf_ife_dump(), the variable 'opt' was partially initialized using a
designatied initializer. While the padding bytes are reamined
uninitialized. nla_put() copies the entire structure into a
netlink message, these uninitialized bytes leaked to userspace.

Initialize the structure with memset before assigning its fields
to ensure all members and padding are cleared prior to beign copied.

This change silences the KMSAN report and prevents potential information
leaks from the kernel memory.

This fix has been tested and validated by syzbot. This patch closes the
bug reported at the following syzkaller link and ensures no infoleak.

Reported-by: syzbot+0c85cae3350b7d486aee@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=0c85cae3350b7d486aee
Tested-by: syzbot+0c85cae3350b7d486aee@syzkaller.appspotmail.com
Fixes: ef6980b6becb ("introduce IFE action")
Signed-off-by: Ranganath V N <vnranganath.20@gmail.com>
---
 net/sched/act_ife.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/net/sched/act_ife.c b/net/sched/act_ife.c
index 107c6d83dc5c..7c6975632fc2 100644
--- a/net/sched/act_ife.c
+++ b/net/sched/act_ife.c
@@ -644,13 +644,15 @@ static int tcf_ife_dump(struct sk_buff *skb, struct tc_action *a, int bind,
 	unsigned char *b = skb_tail_pointer(skb);
 	struct tcf_ife_info *ife = to_ife(a);
 	struct tcf_ife_params *p;
-	struct tc_ife opt = {
-		.index = ife->tcf_index,
-		.refcnt = refcount_read(&ife->tcf_refcnt) - ref,
-		.bindcnt = atomic_read(&ife->tcf_bindcnt) - bind,
-	};
+	struct tc_ife opt;
 	struct tcf_t t;
 
+	memset(&opt, 0, sizeof(opt));
+
+	opt.index = ife->tcf_index,
+	opt.refcnt = refcount_read(&ife->tcf_refcnt) - ref,
+	opt.bindcnt = atomic_read(&ife->tcf_bindcnt) - bind,
+
 	spin_lock_bh(&ife->tcf_lock);
 	opt.action = ife->tcf_action;
 	p = rcu_dereference_protected(ife->params,

-- 
2.43.0

Re: [PATCH v2 1/2] net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak

[Simon Horman]

On Sat, Nov 01, 2025 at 06:04:47PM +0530, Ranganath V N wrote:
> Fix a KMSAN kernel-infoleak detected  by the syzbot .
> 
> [net?] KMSAN: kernel-infoleak in __skb_datagram_iter
> 
> In tcf_ife_dump(), the variable 'opt' was partially initialized using a
> designatied initializer. While the padding bytes are reamined
> uninitialized. nla_put() copies the entire structure into a
> netlink message, these uninitialized bytes leaked to userspace.
> 
> Initialize the structure with memset before assigning its fields
> to ensure all members and padding are cleared prior to beign copied.
> 
> This change silences the KMSAN report and prevents potential information
> leaks from the kernel memory.
> 
> This fix has been tested and validated by syzbot. This patch closes the
> bug reported at the following syzkaller link and ensures no infoleak.
> 
> Reported-by: syzbot+0c85cae3350b7d486aee@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=0c85cae3350b7d486aee
> Tested-by: syzbot+0c85cae3350b7d486aee@syzkaller.appspotmail.com
> Fixes: ef6980b6becb ("introduce IFE action")
> Signed-off-by: Ranganath V N <vnranganath.20@gmail.com>
> ---
>  net/sched/act_ife.c | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/net/sched/act_ife.c b/net/sched/act_ife.c
> index 107c6d83dc5c..7c6975632fc2 100644
> --- a/net/sched/act_ife.c
> +++ b/net/sched/act_ife.c
> @@ -644,13 +644,15 @@ static int tcf_ife_dump(struct sk_buff *skb, struct tc_action *a, int bind,
>  	unsigned char *b = skb_tail_pointer(skb);
>  	struct tcf_ife_info *ife = to_ife(a);
>  	struct tcf_ife_params *p;
> -	struct tc_ife opt = {
> -		.index = ife->tcf_index,
> -		.refcnt = refcount_read(&ife->tcf_refcnt) - ref,
> -		.bindcnt = atomic_read(&ife->tcf_bindcnt) - bind,
> -	};
> +	struct tc_ife opt;
>  	struct tcf_t t;
>  
> +	memset(&opt, 0, sizeof(opt));
> +
> +	opt.index = ife->tcf_index,
> +	opt.refcnt = refcount_read(&ife->tcf_refcnt) - ref,
> +	opt.bindcnt = atomic_read(&ife->tcf_bindcnt) - bind,

I don't think it makes any difference to the compiled code.
But I think it would be clearer to use ';' rather than ','
at the end of each of the three lines above.

Likewise in patch 2/2.

> +
>  	spin_lock_bh(&ife->tcf_lock);
>  	opt.action = ife->tcf_action;
>  	p = rcu_dereference_protected(ife->params,
> 
> -- 
> 2.43.0
> 

[PATCH v2 2/2] net: sched: act_connmark: zero initialize the struct to avoid KMSAN

[Ranganath V N]

zero initialize the struct to avoid the infoleak to the userspace.

Signed-off-by: Ranganath V N <vnranganath.20@gmail.com>
---
 net/sched/act_connmark.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/net/sched/act_connmark.c b/net/sched/act_connmark.c
index 3e89927d7116..cf3cdfaaa34b 100644
--- a/net/sched/act_connmark.c
+++ b/net/sched/act_connmark.c
@@ -195,13 +195,15 @@ static inline int tcf_connmark_dump(struct sk_buff *skb, struct tc_action *a,
 	const struct tcf_connmark_info *ci = to_connmark(a);
 	unsigned char *b = skb_tail_pointer(skb);
 	const struct tcf_connmark_parms *parms;
-	struct tc_connmark opt = {
-		.index   = ci->tcf_index,
-		.refcnt  = refcount_read(&ci->tcf_refcnt) - ref,
-		.bindcnt = atomic_read(&ci->tcf_bindcnt) - bind,
-	};
+	struct tc_connmark opt;
 	struct tcf_t t;
 
+	memset(&opt, 0, sizeof(opt));
+
+	opt.index   = ci->tcf_index,
+	opt.refcnt  = refcount_read(&ci->tcf_refcnt) - ref,
+	opt.bindcnt = atomic_read(&ci->tcf_bindcnt) - bind,
+
 	rcu_read_lock();
 	parms = rcu_dereference(ci->parms);
 

-- 
2.43.0

Re: [PATCH v2 0/2] net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak

[Simon Horman]

On Sat, Nov 01, 2025 at 06:04:46PM +0530, Ranganath V N wrote:
> Fix a KMSAN kernel-infoleak detected  by the syzbot .
> 
> [net?] KMSAN: kernel-infoleak in __skb_datagram_iter
> 
> In tcf_ife_dump(), the variable 'opt' was partially initialized using a
> designatied initializer. While the padding bytes are reamined
> uninitialized. nla_put() copies the entire structure into a
> netlink message, these uninitialized bytes leaked to userspace.
> 
> Initialize the structure with memset before assigning its fields
> to ensure all members and padding are cleared prior to beign copied.

Perhaps not important, but this seems to only describe patch 1/2.

> 
> Signed-off-by: Ranganath V N <vnranganath.20@gmail.com>

Sorry for not looking more carefully at v1.

The presence of this padding seems pretty subtle to me.
And while I agree that your change fixes the problem described.
I wonder if it would be better to make things more obvious
by adding a 2-byte pad member to the structures involved.

...

Re: [PATCH v2 0/2] net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak

[Ranganath V N]

On 11/4/25 19:38, Simon Horman wrote:
> On Sat, Nov 01, 2025 at 06:04:46PM +0530, Ranganath V N wrote:
>> Fix a KMSAN kernel-infoleak detected  by the syzbot .
>>
>> [net?] KMSAN: kernel-infoleak in __skb_datagram_iter
>>
>> In tcf_ife_dump(), the variable 'opt' was partially initialized using a
>> designatied initializer. While the padding bytes are reamined
>> uninitialized. nla_put() copies the entire structure into a
>> netlink message, these uninitialized bytes leaked to userspace.
>>
>> Initialize the structure with memset before assigning its fields
>> to ensure all members and padding are cleared prior to beign copied.
>
> Perhaps not important, but this seems to only describe patch 1/2.
>
>>
>> Signed-off-by: Ranganath V N <vnranganath.20@gmail.com>
>
> Sorry for not looking more carefully at v1.
>
> The presence of this padding seems pretty subtle to me.
> And while I agree that your change fixes the problem described.
> I wonder if it would be better to make things more obvious
> by adding a 2-byte pad member to the structures involved.

Thanks for the input.

One question — even though adding a 2-byte `pad` field silences KMSAN,
would that approach be reliable across all architectures?
Since the actual amount and placement of padding can vary depending on
structure alignment and compiler behavior, I’m wondering if this would only
silence the report on certain builds rather than fixing the root cause.

The current memset-based initialization explicitly clears all bytes in the
structure (including any compiler-inserted padding), which seems safer and
more consistent across architectures.

Also, adding a new member — even a padding field — could potentially alter
the structure size or layout as seen from user space. That might 
unintentionally affect existing user-space expectations.

Do you think relying on a manual pad field is good enough?

regards,  
--Ranganath

Re: [PATCH v2 0/2] net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak

[Simon Horman]

On Wed, Nov 05, 2025 at 03:33:58PM +0530, Ranganath V N wrote:
> On 11/4/25 19:38, Simon Horman wrote:
> > On Sat, Nov 01, 2025 at 06:04:46PM +0530, Ranganath V N wrote:
> >> Fix a KMSAN kernel-infoleak detected  by the syzbot .
> >>
> >> [net?] KMSAN: kernel-infoleak in __skb_datagram_iter
> >>
> >> In tcf_ife_dump(), the variable 'opt' was partially initialized using a
> >> designatied initializer. While the padding bytes are reamined
> >> uninitialized. nla_put() copies the entire structure into a
> >> netlink message, these uninitialized bytes leaked to userspace.
> >>
> >> Initialize the structure with memset before assigning its fields
> >> to ensure all members and padding are cleared prior to beign copied.
> >
> > Perhaps not important, but this seems to only describe patch 1/2.
> >
> >>
> >> Signed-off-by: Ranganath V N <vnranganath.20@gmail.com>
> >
> > Sorry for not looking more carefully at v1.
> >
> > The presence of this padding seems pretty subtle to me.
> > And while I agree that your change fixes the problem described.
> > I wonder if it would be better to make things more obvious
> > by adding a 2-byte pad member to the structures involved.
> 
> Thanks for the input.
> 
> One question — even though adding a 2-byte `pad` field silences KMSAN,
> would that approach be reliable across all architectures?
> Since the actual amount and placement of padding can vary depending on
> structure alignment and compiler behavior, I’m wondering if this would only
> silence the report on certain builds rather than fixing the root cause.
> 
> The current memset-based initialization explicitly clears all bytes in the
> structure (including any compiler-inserted padding), which seems safer and
> more consistent across architectures.
> 
> Also, adding a new member — even a padding field — could potentially alter
> the structure size or layout as seen from user space. That might 
> unintentionally affect existing user-space expectations.
> 
> Do you think relying on a manual pad field is good enough?

I think these are the right questions to ask.

My thinking is that structures will be padded to a multiple
of either 4 or 8 bytes, depending on the architecture.

And my observation is that that the unpadded length of both of the structures
in question are 22 bytes. And that on x86_64 they are padded to 24 bytes.
Which is divisible by both 4 and 8. So I assume this will be consistent
for all architectures. If so, I think this would address the questions you
raised.

I do, however, agree that your current memset-based approach is safer
in the sense that it carries a lower risk of breaking things because
it has fewer assumptions (that we have thought of so far).

Re: [PATCH v2 0/2] net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak

[Jamal Hadi Salim]

On Wed, Nov 5, 2025 at 7:59 AM Simon Horman <horms@kernel.org> wrote:
>
> On Wed, Nov 05, 2025 at 03:33:58PM +0530, Ranganath V N wrote:
> > On 11/4/25 19:38, Simon Horman wrote:
> > > On Sat, Nov 01, 2025 at 06:04:46PM +0530, Ranganath V N wrote:
> > >> Fix a KMSAN kernel-infoleak detected  by the syzbot .
> > >>
> > >> [net?] KMSAN: kernel-infoleak in __skb_datagram_iter
> > >>
> > >> In tcf_ife_dump(), the variable 'opt' was partially initialized using a
> > >> designatied initializer. While the padding bytes are reamined
> > >> uninitialized. nla_put() copies the entire structure into a
> > >> netlink message, these uninitialized bytes leaked to userspace.
> > >>
> > >> Initialize the structure with memset before assigning its fields
> > >> to ensure all members and padding are cleared prior to beign copied.
> > >
> > > Perhaps not important, but this seems to only describe patch 1/2.
> > >
> > >>
> > >> Signed-off-by: Ranganath V N <vnranganath.20@gmail.com>
> > >
> > > Sorry for not looking more carefully at v1.
> > >
> > > The presence of this padding seems pretty subtle to me.
> > > And while I agree that your change fixes the problem described.
> > > I wonder if it would be better to make things more obvious
> > > by adding a 2-byte pad member to the structures involved.
> >
> > Thanks for the input.
> >
> > One question — even though adding a 2-byte `pad` field silences KMSAN,
> > would that approach be reliable across all architectures?
> > Since the actual amount and placement of padding can vary depending on
> > structure alignment and compiler behavior, I’m wondering if this would only
> > silence the report on certain builds rather than fixing the root cause.
> >
> > The current memset-based initialization explicitly clears all bytes in the
> > structure (including any compiler-inserted padding), which seems safer and
> > more consistent across architectures.
> >
> > Also, adding a new member — even a padding field — could potentially alter
> > the structure size or layout as seen from user space. That might
> > unintentionally affect existing user-space expectations.
> >
> > Do you think relying on a manual pad field is good enough?
>
> I think these are the right questions to ask.
>
> My thinking is that structures will be padded to a multiple
> of either 4 or 8 bytes, depending on the architecture.
>
> And my observation is that that the unpadded length of both of the structures
> in question are 22 bytes. And that on x86_64 they are padded to 24 bytes.
> Which is divisible by both 4 and 8. So I assume this will be consistent
> for all architectures. If so, I think this would address the questions you
> raised.
>
> I do, however, agree that your current memset-based approach is safer
> in the sense that it carries a lower risk of breaking things because
> it has fewer assumptions (that we have thought of so far).

+1
My view is lets fix the immediate leak issue with the memset, and a
subsequent patch can add the padding if necessary.

cheers,
jamal

Re: [PATCH v2 0/2] net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak

[Simon Horman]

On Wed, Nov 05, 2025 at 10:09:37AM -0500, Jamal Hadi Salim wrote:
> On Wed, Nov 5, 2025 at 7:59 AM Simon Horman <horms@kernel.org> wrote:
> >
> > On Wed, Nov 05, 2025 at 03:33:58PM +0530, Ranganath V N wrote:
> > > On 11/4/25 19:38, Simon Horman wrote:
> > > > On Sat, Nov 01, 2025 at 06:04:46PM +0530, Ranganath V N wrote:
> > > >> Fix a KMSAN kernel-infoleak detected  by the syzbot .
> > > >>
> > > >> [net?] KMSAN: kernel-infoleak in __skb_datagram_iter
> > > >>
> > > >> In tcf_ife_dump(), the variable 'opt' was partially initialized using a
> > > >> designatied initializer. While the padding bytes are reamined
> > > >> uninitialized. nla_put() copies the entire structure into a
> > > >> netlink message, these uninitialized bytes leaked to userspace.
> > > >>
> > > >> Initialize the structure with memset before assigning its fields
> > > >> to ensure all members and padding are cleared prior to beign copied.
> > > >
> > > > Perhaps not important, but this seems to only describe patch 1/2.
> > > >
> > > >>
> > > >> Signed-off-by: Ranganath V N <vnranganath.20@gmail.com>
> > > >
> > > > Sorry for not looking more carefully at v1.
> > > >
> > > > The presence of this padding seems pretty subtle to me.
> > > > And while I agree that your change fixes the problem described.
> > > > I wonder if it would be better to make things more obvious
> > > > by adding a 2-byte pad member to the structures involved.
> > >
> > > Thanks for the input.
> > >
> > > One question — even though adding a 2-byte `pad` field silences KMSAN,
> > > would that approach be reliable across all architectures?
> > > Since the actual amount and placement of padding can vary depending on
> > > structure alignment and compiler behavior, I’m wondering if this would only
> > > silence the report on certain builds rather than fixing the root cause.
> > >
> > > The current memset-based initialization explicitly clears all bytes in the
> > > structure (including any compiler-inserted padding), which seems safer and
> > > more consistent across architectures.
> > >
> > > Also, adding a new member — even a padding field — could potentially alter
> > > the structure size or layout as seen from user space. That might
> > > unintentionally affect existing user-space expectations.
> > >
> > > Do you think relying on a manual pad field is good enough?
> >
> > I think these are the right questions to ask.
> >
> > My thinking is that structures will be padded to a multiple
> > of either 4 or 8 bytes, depending on the architecture.
> >
> > And my observation is that that the unpadded length of both of the structures
> > in question are 22 bytes. And that on x86_64 they are padded to 24 bytes.
> > Which is divisible by both 4 and 8. So I assume this will be consistent
> > for all architectures. If so, I think this would address the questions you
> > raised.
> >
> > I do, however, agree that your current memset-based approach is safer
> > in the sense that it carries a lower risk of breaking things because
> > it has fewer assumptions (that we have thought of so far).
> 
> +1
> My view is lets fix the immediate leak issue with the memset, and a
> subsequent patch can add the padding if necessary.

Sure, no objections from my side.

Re: [PATCH v2 0/2] net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak

[Ranganath V N]

On 11/6/25 00:43, Simon Horman wrote:
> On Wed, Nov 05, 2025 at 10:09:37AM -0500, Jamal Hadi Salim wrote:
>> On Wed, Nov 5, 2025 at 7:59 AM Simon Horman <horms@kernel.org> wrote:
>>>
>>> On Wed, Nov 05, 2025 at 03:33:58PM +0530, Ranganath V N wrote:
>>>> On 11/4/25 19:38, Simon Horman wrote:
>>>>> On Sat, Nov 01, 2025 at 06:04:46PM +0530, Ranganath V N wrote:
>>>>>> Fix a KMSAN kernel-infoleak detected  by the syzbot .
>>>>>>
>>>>>> [net?] KMSAN: kernel-infoleak in __skb_datagram_iter
>>>>>>
>>>>>> In tcf_ife_dump(), the variable 'opt' was partially initialized using a
>>>>>> designatied initializer. While the padding bytes are reamined
>>>>>> uninitialized. nla_put() copies the entire structure into a
>>>>>> netlink message, these uninitialized bytes leaked to userspace.
>>>>>>
>>>>>> Initialize the structure with memset before assigning its fields
>>>>>> to ensure all members and padding are cleared prior to beign copied.
>>>>>
>>>>> Perhaps not important, but this seems to only describe patch 1/2.
>>>>>
>>>>>>
>>>>>> Signed-off-by: Ranganath V N <vnranganath.20@gmail.com>
>>>>>
>>>>> Sorry for not looking more carefully at v1.
>>>>>
>>>>> The presence of this padding seems pretty subtle to me.
>>>>> And while I agree that your change fixes the problem described.
>>>>> I wonder if it would be better to make things more obvious
>>>>> by adding a 2-byte pad member to the structures involved.
>>>>
>>>> Thanks for the input.
>>>>
>>>> One question — even though adding a 2-byte `pad` field silences KMSAN,
>>>> would that approach be reliable across all architectures?
>>>> Since the actual amount and placement of padding can vary depending on
>>>> structure alignment and compiler behavior, I’m wondering if this would only
>>>> silence the report on certain builds rather than fixing the root cause.
>>>>
>>>> The current memset-based initialization explicitly clears all bytes in the
>>>> structure (including any compiler-inserted padding), which seems safer and
>>>> more consistent across architectures.
>>>>
>>>> Also, adding a new member — even a padding field — could potentially alter
>>>> the structure size or layout as seen from user space. That might
>>>> unintentionally affect existing user-space expectations.
>>>>
>>>> Do you think relying on a manual pad field is good enough?
>>>
>>> I think these are the right questions to ask.
>>>
>>> My thinking is that structures will be padded to a multiple
>>> of either 4 or 8 bytes, depending on the architecture.
>>>
>>> And my observation is that that the unpadded length of both of the structures
>>> in question are 22 bytes. And that on x86_64 they are padded to 24 bytes.
>>> Which is divisible by both 4 and 8. So I assume this will be consistent
>>> for all architectures. If so, I think this would address the questions you
>>> raised.
>>>
>>> I do, however, agree that your current memset-based approach is safer
>>> in the sense that it carries a lower risk of breaking things because
>>> it has fewer assumptions (that we have thought of so far).
>>
>> +1
>> My view is lets fix the immediate leak issue with the memset, and a
>> subsequent patch can add the padding if necessary.
>
> Sure, no objections from my side.

Thanks for the clarification.

I'll send the new patch series(v3) with fix(missed ;)
I'll keep the current change limited to the memset fix to resolve the
issue. Also, I've noticed that similar uninitialized structure
patterns exist in a few other locations in the net code.

Thanks for the review.