Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y

Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y

[Ujjal Roy]

Hi Greg,

Please consider backporting the following bridge multicast fix series to 6.1.y, 6.6.y, 6.12.y, 6.18.y and 7.0.y.

726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation")
12cfb4ecc471 ("ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()")
95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields")
e51560f4220a ("ipv6: mld: encode multicast exponential fields")
529dbe762de0 ("selftests: net: bridge: add MRC and QQIC field encoding tests")

This series was merged via: db314398f618 ("net: bridge: mcast: support
exponential field encoding")

I checked that the above upstream commits cherry-picked cleanly onto the following stable branches:

linux-7.0.y
linux-6.18.y
linux-6.12.y
linux-6.6.y
linux-6.1.y

Thanks,
Ujjal

Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y

[Greg KH]

On Thu, Jul 09, 2026 at 10:13:27AM +0000, Ujjal Roy wrote:
> Hi Greg,
> 
> Please consider backporting the following bridge multicast fix series to 6.1.y, 6.6.y, 6.12.y, 6.18.y and 7.0.y.
> 
> 726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation")
> 12cfb4ecc471 ("ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()")
> 95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields")
> e51560f4220a ("ipv6: mld: encode multicast exponential fields")
> 529dbe762de0 ("selftests: net: bridge: add MRC and QQIC field encoding tests")

Why is any of this needed in older kernels?

And 7.0.y is long end-of-life.

And why, if this does fix issues, was it not tagged for stable to start
with?

thanks,

greg k-h

Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y

[Ujjal Roy]

On Thu, Jul 9, 2026 at 4:34 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Jul 09, 2026 at 10:13:27AM +0000, Ujjal Roy wrote:
> > Hi Greg,
> >
> > Please consider backporting the following bridge multicast fix series to 6.1.y, 6.6.y, 6.12.y, 6.18.y and 7.0.y.
> >
> > 726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation")
> > 12cfb4ecc471 ("ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()")
> > 95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields")
> > e51560f4220a ("ipv6: mld: encode multicast exponential fields")
> > 529dbe762de0 ("selftests: net: bridge: add MRC and QQIC field encoding tests")
>
> Why is any of this needed in older kernels?
>
> And 7.0.y is long end-of-life.
>
> And why, if this does fix issues, was it not tagged for stable to start
> with?
>
> thanks,
>
> greg k-h

I already explained this in the email thread, "Please backport bridge
multicast exponential field encoding fix series to stable kernels".

Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y

[Greg KH]

On Thu, Jul 09, 2026 at 06:12:40PM +0530, Ujjal Roy wrote:
> On Thu, Jul 9, 2026 at 4:34 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Jul 09, 2026 at 10:13:27AM +0000, Ujjal Roy wrote:
> > > Hi Greg,
> > >
> > > Please consider backporting the following bridge multicast fix series to 6.1.y, 6.6.y, 6.12.y, 6.18.y and 7.0.y.
> > >
> > > 726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation")
> > > 12cfb4ecc471 ("ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()")
> > > 95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields")
> > > e51560f4220a ("ipv6: mld: encode multicast exponential fields")
> > > 529dbe762de0 ("selftests: net: bridge: add MRC and QQIC field encoding tests")
> >
> > Why is any of this needed in older kernels?
> >
> > And 7.0.y is long end-of-life.
> >
> > And why, if this does fix issues, was it not tagged for stable to start
> > with?
> >
> > thanks,
> >
> > greg k-h
> 
> I already explained this in the email thread, "Please backport bridge
> multicast exponential field encoding fix series to stable kernels".

Sorry, but that's not here (remember, some of us get 1000+ emails a
day.)

Please explain why patches need to be backported when asking for them to
be backported.

thanks,

greg k-h

Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y

[Ujjal Roy]

On Thu, Jul 9, 2026 at 6:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Jul 09, 2026 at 06:12:40PM +0530, Ujjal Roy wrote:
> > On Thu, Jul 9, 2026 at 4:34 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Thu, Jul 09, 2026 at 10:13:27AM +0000, Ujjal Roy wrote:
> > > > Hi Greg,
> > > >
> > > > Please consider backporting the following bridge multicast fix series to 6.1.y, 6.6.y, 6.12.y, 6.18.y and 7.0.y.
> > > >
> > > > 726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation")
> > > > 12cfb4ecc471 ("ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()")
> > > > 95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields")
> > > > e51560f4220a ("ipv6: mld: encode multicast exponential fields")
> > > > 529dbe762de0 ("selftests: net: bridge: add MRC and QQIC field encoding tests")
> > >
> > > Why is any of this needed in older kernels?
> > >
> > > And 7.0.y is long end-of-life.
> > >
> > > And why, if this does fix issues, was it not tagged for stable to start
> > > with?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > I already explained this in the email thread, "Please backport bridge
> > multicast exponential field encoding fix series to stable kernels".
>
> Sorry, but that's not here (remember, some of us get 1000+ emails a
> day.)
>
> Please explain why patches need to be backported when asking for them to
> be backported.
>
> thanks,
>
> greg k-h

Sorry for breaking the thread. I understand your point, I will
maintain this in the future.
How should I send the patchset that addresses the conflicts on 5.10.y
and 7.1.y? Shall I send the conflicts patchset as a series via a
different thread or how? I've never done this before, so I'm asking.

Here is the explanation for why the patches need to be backported:

History: The multicast stack currently supports decoding of IGMPv3 and
MLDv2 exponential timer field encodings, but lacks the corresponding
encoding logic when generating multicast query packets. As a result,
query intervals and response codes exceeding the linear encoding range
can be transmitted incorrectly. This can cause multicast queriers and
listeners to interpret different timing values, resulting in protocol
interoperability issues, membership timeouts, and premature multicast
group expiration.

Testing: The series adds the missing encoding support for both IGMPv3
and MLDv2 and includes selftests that validate the behavior.
I backported the series to v6.6.123.2 and verified the accompanying
selftests. The selftests fail on the unpatched kernel and pass after
applying the series, demonstrating both the bug and the effectiveness
of the fix.

Given that this is a protocol correctness issue affecting multicast
query generation, please consider backporting the complete series to
all applicable stable kernels.

Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y

[Greg KH]

On Thu, Jul 09, 2026 at 06:35:04PM +0530, Ujjal Roy wrote:
> On Thu, Jul 9, 2026 at 6:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Jul 09, 2026 at 06:12:40PM +0530, Ujjal Roy wrote:
> > > On Thu, Jul 9, 2026 at 4:34 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Thu, Jul 09, 2026 at 10:13:27AM +0000, Ujjal Roy wrote:
> > > > > Hi Greg,
> > > > >
> > > > > Please consider backporting the following bridge multicast fix series to 6.1.y, 6.6.y, 6.12.y, 6.18.y and 7.0.y.
> > > > >
> > > > > 726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation")
> > > > > 12cfb4ecc471 ("ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()")
> > > > > 95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields")
> > > > > e51560f4220a ("ipv6: mld: encode multicast exponential fields")
> > > > > 529dbe762de0 ("selftests: net: bridge: add MRC and QQIC field encoding tests")
> > > >
> > > > Why is any of this needed in older kernels?
> > > >
> > > > And 7.0.y is long end-of-life.
> > > >
> > > > And why, if this does fix issues, was it not tagged for stable to start
> > > > with?
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > I already explained this in the email thread, "Please backport bridge
> > > multicast exponential field encoding fix series to stable kernels".
> >
> > Sorry, but that's not here (remember, some of us get 1000+ emails a
> > day.)
> >
> > Please explain why patches need to be backported when asking for them to
> > be backported.
> >
> > thanks,
> >
> > greg k-h
> 
> Sorry for breaking the thread. I understand your point, I will
> maintain this in the future.
> How should I send the patchset that addresses the conflicts on 5.10.y
> and 7.1.y? Shall I send the conflicts patchset as a series via a
> different thread or how? I've never done this before, so I'm asking.
> 
> Here is the explanation for why the patches need to be backported:
> 
> History: The multicast stack currently supports decoding of IGMPv3 and
> MLDv2 exponential timer field encodings, but lacks the corresponding
> encoding logic when generating multicast query packets. As a result,
> query intervals and response codes exceeding the linear encoding range
> can be transmitted incorrectly. This can cause multicast queriers and
> listeners to interpret different timing values, resulting in protocol
> interoperability issues, membership timeouts, and premature multicast
> group expiration.
> 
> Testing: The series adds the missing encoding support for both IGMPv3
> and MLDv2 and includes selftests that validate the behavior.
> I backported the series to v6.6.123.2 and verified the accompanying
> selftests. The selftests fail on the unpatched kernel and pass after
> applying the series, demonstrating both the bug and the effectiveness
> of the fix.
> 
> Given that this is a protocol correctness issue affecting multicast
> query generation, please consider backporting the complete series to
> all applicable stable kernels.
> 

But this really seems like a new feature being added, it's not fixing a
regression of something that previously worked, right?

WHy can't people just update to the latest kernel release to get this if
they need it for their environments?

thanks,

greg k-h

Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y

[Ujjal Roy]

On Thu, Jul 9, 2026 at 7:52 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Jul 09, 2026 at 06:35:04PM +0530, Ujjal Roy wrote:
> > On Thu, Jul 9, 2026 at 6:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Thu, Jul 09, 2026 at 06:12:40PM +0530, Ujjal Roy wrote:
> > > > On Thu, Jul 9, 2026 at 4:34 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Thu, Jul 09, 2026 at 10:13:27AM +0000, Ujjal Roy wrote:
> > > > > > Hi Greg,
> > > > > >
> > > > > > Please consider backporting the following bridge multicast fix series to 6.1.y, 6.6.y, 6.12.y, 6.18.y and 7.0.y.
> > > > > >
> > > > > > 726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation")
> > > > > > 12cfb4ecc471 ("ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()")
> > > > > > 95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields")
> > > > > > e51560f4220a ("ipv6: mld: encode multicast exponential fields")
> > > > > > 529dbe762de0 ("selftests: net: bridge: add MRC and QQIC field encoding tests")
> > > > >
> > > > > Why is any of this needed in older kernels?
> > > > >
> > > > > And 7.0.y is long end-of-life.
> > > > >
> > > > > And why, if this does fix issues, was it not tagged for stable to start
> > > > > with?
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > >
> > > > I already explained this in the email thread, "Please backport bridge
> > > > multicast exponential field encoding fix series to stable kernels".
> > >
> > > Sorry, but that's not here (remember, some of us get 1000+ emails a
> > > day.)
> > >
> > > Please explain why patches need to be backported when asking for them to
> > > be backported.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Sorry for breaking the thread. I understand your point, I will
> > maintain this in the future.
> > How should I send the patchset that addresses the conflicts on 5.10.y
> > and 7.1.y? Shall I send the conflicts patchset as a series via a
> > different thread or how? I've never done this before, so I'm asking.
> >
> > Here is the explanation for why the patches need to be backported:
> >
> > History: The multicast stack currently supports decoding of IGMPv3 and
> > MLDv2 exponential timer field encodings, but lacks the corresponding
> > encoding logic when generating multicast query packets. As a result,
> > query intervals and response codes exceeding the linear encoding range
> > can be transmitted incorrectly. This can cause multicast queriers and
> > listeners to interpret different timing values, resulting in protocol
> > interoperability issues, membership timeouts, and premature multicast
> > group expiration.
> >
> > Testing: The series adds the missing encoding support for both IGMPv3
> > and MLDv2 and includes selftests that validate the behavior.
> > I backported the series to v6.6.123.2 and verified the accompanying
> > selftests. The selftests fail on the unpatched kernel and pass after
> > applying the series, demonstrating both the bug and the effectiveness
> > of the fix.
> >
> > Given that this is a protocol correctness issue affecting multicast
> > query generation, please consider backporting the complete series to
> > all applicable stable kernels.
> >
>
> But this really seems like a new feature being added, it's not fixing a
> regression of something that previously worked, right?
>
> WHy can't people just update to the latest kernel release to get this if
> they need it for their environments?
>
> thanks,
>
> greg k-h

This is a corner case when people set the query timer value higher
than 128. People usually use the default value and don't change it, so
they may not encounter this issue. But I found it when I changed the
value during some extensive validation of protocol timeouts.

If one host doesn't have this fix, clients will observe premature
multicast group expiration. For example, a set-top box channel might
disconnect early.

But we can ignore this until few more people request this fix for older kernels.

Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y

[Ujjal Roy]

On Thu, Jul 9, 2026 at 8:43 PM Ujjal Roy <royujjal@gmail.com> wrote:
>
> On Thu, Jul 9, 2026 at 7:52 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Jul 09, 2026 at 06:35:04PM +0530, Ujjal Roy wrote:
> > > On Thu, Jul 9, 2026 at 6:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Thu, Jul 09, 2026 at 06:12:40PM +0530, Ujjal Roy wrote:
> > > > > On Thu, Jul 9, 2026 at 4:34 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Thu, Jul 09, 2026 at 10:13:27AM +0000, Ujjal Roy wrote:
> > > > > > > Hi Greg,
> > > > > > >
> > > > > > > Please consider backporting the following bridge multicast fix series to 6.1.y, 6.6.y, 6.12.y, 6.18.y and 7.0.y.
> > > > > > >
> > > > > > > 726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation")
> > > > > > > 12cfb4ecc471 ("ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()")
> > > > > > > 95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields")
> > > > > > > e51560f4220a ("ipv6: mld: encode multicast exponential fields")
> > > > > > > 529dbe762de0 ("selftests: net: bridge: add MRC and QQIC field encoding tests")
> > > > > >
> > > > > > Why is any of this needed in older kernels?
> > > > > >
> > > > > > And 7.0.y is long end-of-life.
> > > > > >
> > > > > > And why, if this does fix issues, was it not tagged for stable to start
> > > > > > with?
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > greg k-h
> > > > >
> > > > > I already explained this in the email thread, "Please backport bridge
> > > > > multicast exponential field encoding fix series to stable kernels".
> > > >
> > > > Sorry, but that's not here (remember, some of us get 1000+ emails a
> > > > day.)
> > > >
> > > > Please explain why patches need to be backported when asking for them to
> > > > be backported.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > Sorry for breaking the thread. I understand your point, I will
> > > maintain this in the future.
> > > How should I send the patchset that addresses the conflicts on 5.10.y
> > > and 7.1.y? Shall I send the conflicts patchset as a series via a
> > > different thread or how? I've never done this before, so I'm asking.
> > >
> > > Here is the explanation for why the patches need to be backported:
> > >
> > > History: The multicast stack currently supports decoding of IGMPv3 and
> > > MLDv2 exponential timer field encodings, but lacks the corresponding
> > > encoding logic when generating multicast query packets. As a result,
> > > query intervals and response codes exceeding the linear encoding range
> > > can be transmitted incorrectly. This can cause multicast queriers and
> > > listeners to interpret different timing values, resulting in protocol
> > > interoperability issues, membership timeouts, and premature multicast
> > > group expiration.
> > >
> > > Testing: The series adds the missing encoding support for both IGMPv3
> > > and MLDv2 and includes selftests that validate the behavior.
> > > I backported the series to v6.6.123.2 and verified the accompanying
> > > selftests. The selftests fail on the unpatched kernel and pass after
> > > applying the series, demonstrating both the bug and the effectiveness
> > > of the fix.
> > >
> > > Given that this is a protocol correctness issue affecting multicast
> > > query generation, please consider backporting the complete series to
> > > all applicable stable kernels.
> > >
> >
> > But this really seems like a new feature being added, it's not fixing a
> > regression of something that previously worked, right?
> >
> > WHy can't people just update to the latest kernel release to get this if
> > they need it for their environments?
> >
> > thanks,
> >
> > greg k-h
>
> This is a corner case when people set the query timer value higher
> than 128. People usually use the default value and don't change it, so
> they may not encounter this issue. But I found it when I changed the
> value during some extensive validation of protocol timeouts.
>
> If one host doesn't have this fix, clients will observe premature
> multicast group expiration. For example, a set-top box channel might
> disconnect early.
>
> But we can ignore this until few more people request this fix for older kernels.

Last two patches actually fix the timeout issue. Below one fixes QQIC
encoding BUG for IPv4.

95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields")
@@ -780,11 +780,9 @@ static struct sk_buff
*br_ip4_multicast_alloc_query(struct net_bridge *br,
        case 3:
                ihv3 = igmpv3_query_hdr(skb);
                ihv3->type = IGMP_HOST_MEMBERSHIP_QUERY;
-               ihv3->code = (group ? br->multicast_last_member_interval :
-                                     br->multicast_query_response_interval) /
-                            (HZ / IGMP_TIMER_SCALE);
+               ihv3->code = igmpv3_mrc(mrt / (HZ / IGMP_TIMER_SCALE));
                ihv3->group = group;
-               ihv3->qqic = br->multicast_query_interval / HZ;
+               ihv3->qqic = igmpv3_qqic(br->multicast_query_interval
/ HZ);  // This was not encoding earlier

Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y

[Andrew Lunn]

> > > History: The multicast stack currently supports decoding of IGMPv3 and
> > > MLDv2 exponential timer field encodings, but lacks the corresponding
> > > encoding logic when generating multicast query packets.

RFC 3376 says:

4.1.1. Max Resp Code

   The Max Resp Code field specifies the maximum time allowed before
   sending a responding report.  The actual time allowed, called the Max
   Resp Time, is represented in units of 1/10 second and is derived from
   the Max Resp Code as follows:

   If Max Resp Code < 128, Max Resp Time = Max Resp Code

   If Max Resp Code >= 128, Max Resp Code represents a floating-point
   value as follows:

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |1| exp | mant  |
      +-+-+-+-+-+-+-+-+

   Max Resp Time = (mant | 0x10) << (exp + 3)

   Small values of Max Resp Time allow IGMPv3 routers to tune the "leave
   latency" (the time between the moment the last host leaves a group
   and the moment the routing protocol is notified that there are no
   more members).  Larger values, especially in the exponential range,
   allow tuning of the burstiness of IGMP traffic on a network.

Let me check i understand the issue. If the user configures a value >
127, linux continues to use the linear encoding, but a peer decodes it
as a floating value.

128 linear is 0 | 0x10) << (0 + 3) = 0x40 = 64. So the peer sends the
reports earlier than required?

255 linear is (0xf | 0x10) << (7 + 3) = 0x1F0000 = 2031616. So the
peer can send the reports much later than the 255 1/10 of a second
than userspace expected.

What is useful here is, 'maximum time allowed'. The RFC does not
appear to say how to pick a value between 0 and the maximum time
allowed. Which gives us some flexibility.

I think a much simpler fix for stable is to clamp the user space
request for setting the max response time to 127. That seems like a
one line patch.

    Andrew

Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y

[Ujjal Roy]

On Fri, Jul 10, 2026 at 1:31 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > > History: The multicast stack currently supports decoding of IGMPv3 and
> > > > MLDv2 exponential timer field encodings, but lacks the corresponding
> > > > encoding logic when generating multicast query packets.
>
> RFC 3376 says:
>
> 4.1.1. Max Resp Code
>
>    The Max Resp Code field specifies the maximum time allowed before
>    sending a responding report.  The actual time allowed, called the Max
>    Resp Time, is represented in units of 1/10 second and is derived from
>    the Max Resp Code as follows:
Here I can give you some input. Default value is 10 seconds for which
the protocol value sent on the wire will be 100. This means 100 *
(1/10 second) = 10s. Similarly, setting just 14 seconds will cause
issues. The protocol value transmitted on the wire is 140, which, when
decoded as a linear value, results in 224. Similarly, values greater
than 25.5 seconds cannot be represented directly in the 8-bit field.

>
> Let me check i understand the issue. If the user configures a value >
> 127, linux continues to use the linear encoding, but a peer decodes it
> as a floating value.
Yes, you are right and that is what it does till now. And the Kernel
applies same to the QQIC field as well.

>
> 128 linear is 0 | 0x10) << (0 + 3) = 0x40 = 64. So the peer sends the
> reports earlier than required?
No, it is not 64. This becomes (0x10 << 3) = 0x80 = 128 again.

>
> 255 linear is (0xf | 0x10) << (7 + 3) = 0x1F0000 = 2031616. So the
> peer can send the reports much later than the 255 1/10 of a second
> than userspace expected.
Yes, you are right. But the calculation is incorrect; it becomes
0x7C00, which is 31744.

>
> What is useful here is, 'maximum time allowed'. The RFC does not
> appear to say how to pick a value between 0 and the maximum time
> allowed. Which gives us some flexibility.
Yes. However, this can lead to excessively slow membership
convergence, increased leave latency, and in some scenarios may cause
multicast membership state to expire before reports are received.

>
> I think a much simpler fix for stable is to clamp the user space
> request for setting the max response time to 127. That seems like a
> one line patch.
In mainline I encoded the value according to the RFC. We can clamp to
127 in stables, if we are not willing to take the entire series. This
will force user to use value < 128. Also, please consider QQIC; a
similar encoding issue persists.

>
>     Andrew
>

On Fri, Jul 10, 2026 at 1:31 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > > History: The multicast stack currently supports decoding of IGMPv3 and
> > > > MLDv2 exponential timer field encodings, but lacks the corresponding
> > > > encoding logic when generating multicast query packets.
>
> RFC 3376 says:
>
> 4.1.1. Max Resp Code
>
>    The Max Resp Code field specifies the maximum time allowed before
>    sending a responding report.  The actual time allowed, called the Max
>    Resp Time, is represented in units of 1/10 second and is derived from
>    the Max Resp Code as follows:
>
>    If Max Resp Code < 128, Max Resp Time = Max Resp Code
>
>    If Max Resp Code >= 128, Max Resp Code represents a floating-point
>    value as follows:
>
>        0 1 2 3 4 5 6 7
>       +-+-+-+-+-+-+-+-+
>       |1| exp | mant  |
>       +-+-+-+-+-+-+-+-+
>
>    Max Resp Time = (mant | 0x10) << (exp + 3)
>
>    Small values of Max Resp Time allow IGMPv3 routers to tune the "leave
>    latency" (the time between the moment the last host leaves a group
>    and the moment the routing protocol is notified that there are no
>    more members).  Larger values, especially in the exponential range,
>    allow tuning of the burstiness of IGMP traffic on a network.
>
> Let me check i understand the issue. If the user configures a value >
> 127, linux continues to use the linear encoding, but a peer decodes it
> as a floating value.
>
> 128 linear is 0 | 0x10) << (0 + 3) = 0x40 = 64. So the peer sends the
> reports earlier than required?
>
> 255 linear is (0xf | 0x10) << (7 + 3) = 0x1F0000 = 2031616. So the
> peer can send the reports much later than the 255 1/10 of a second
> than userspace expected.
>
> What is useful here is, 'maximum time allowed'. The RFC does not
> appear to say how to pick a value between 0 and the maximum time
> allowed. Which gives us some flexibility.
>
> I think a much simpler fix for stable is to clamp the user space
> request for setting the max response time to 127. That seems like a
> one line patch.
>
>     Andrew
>

Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y

[Andrew Lunn]

On Fri, Jul 10, 2026 at 02:40:39PM +0530, Ujjal Roy wrote:
> On Fri, Jul 10, 2026 at 1:31 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > > > > History: The multicast stack currently supports decoding of IGMPv3 and
> > > > > MLDv2 exponential timer field encodings, but lacks the corresponding
> > > > > encoding logic when generating multicast query packets.
> >
> > RFC 3376 says:
> >
> > 4.1.1. Max Resp Code
> >
> >    The Max Resp Code field specifies the maximum time allowed before
> >    sending a responding report.  The actual time allowed, called the Max
> >    Resp Time, is represented in units of 1/10 second and is derived from
> >    the Max Resp Code as follows:
> Here I can give you some input. Default value is 10 seconds for which
> the protocol value sent on the wire will be 100. This means 100 *
> (1/10 second) = 10s. Similarly, setting just 14 seconds will cause
> issues. The protocol value transmitted on the wire is 140, which, when
> decoded as a linear value, results in 224. Similarly, values greater
> than 25.5 seconds cannot be represented directly in the 8-bit field.
> 
> >
> > Let me check i understand the issue. If the user configures a value >
> > 127, linux continues to use the linear encoding, but a peer decodes it
> > as a floating value.
> Yes, you are right and that is what it does till now. And the Kernel
> applies same to the QQIC field as well.
> 
> >
> > 128 linear is 0 | 0x10) << (0 + 3) = 0x40 = 64. So the peer sends the
> > reports earlier than required?
> No, it is not 64. This becomes (0x10 << 3) = 0x80 = 128 again.
> 
> >
> > 255 linear is (0xf | 0x10) << (7 + 3) = 0x1F0000 = 2031616. So the
> > peer can send the reports much later than the 255 1/10 of a second
> > than userspace expected.
> Yes, you are right. But the calculation is incorrect; it becomes
> 0x7C00, which is 31744.

Thanks for correcting my maths.

> > I think a much simpler fix for stable is to clamp the user space
> > request for setting the max response time to 127. That seems like a
> > one line patch.
> In mainline I encoded the value according to the RFC. We can clamp to
> 127 in stables, if we are not willing to take the entire series. This
> will force user to use value < 128. Also, please consider QQIC; a
> similar encoding issue persists.

It does not force the users to use a value < 128. You would need to
return EINVAL for that, which i'm not proposing. Returning an error
could break user space.

By clamping to 127, we don't break user space, but we do avoid the
kernel bug, and at least to my superficial reading of the RFC, we are
"language lawyer" compliant with the RFC.

	Andrew