NACK: [SRU][J/N][PATCH v3 0/1] CVE-2025-37752

[Ian Whitfield]

On Mon, Jun 16, 2025 at 04:38:43PM -0700, Tim Whisonant wrote:
> SRU Justification:
> 
> [Impact]
> 
> net_sched: sch_sfq: move the limit validation
> 
> It is not sufficient to directly validate the limit on the data that
> the user passes as it can be updated based on how the other parameters
> are changed.
> 
> Move the check at the end of the configuration update process to also
> catch scenarios where the limit is indirectly updated, for example
> with the following configurations:
> 
> tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1
> tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1
> 
> This fixes the following syzkaller reported crash:
> 
> ------------[ cut here ]------------
> UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6
> index 65535 is out of range for type 'struct sfq_head[128]'
> CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:94 [inline]
>  dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120
>  ubsan_epilogue lib/ubsan.c:231 [inline]
>  __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429
>  sfq_link net/sched/sch_sfq.c:203 [inline]
>  sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231
>  sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493
>  sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518
>  qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035
>  tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339
>  qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035
>  dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311
>  netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline]
>  dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375
> 
> [Fix]
> 
> Plucky:   fixed separately
> Oracular: fixed separately
> Noble:    applied Focal patches
> Jammy:    applied Focal patches
> Focal:    patch sent to ESM ML
> Bionic:   patch sent to ESM ML
> Xenial:   patch sent to ESM ML
> Trusty:   out of scope (medium CVE)
> 
> [Test Plan]
> 
> Compile and boot tested.
> 
> [Where problems could occur]
> 
> The changes occur in the network stochastic fairness queueing
> discipline implementation. Issues may appear as anomolies related
> to that queueing discipline.
> 
> [Notes]
> 
> v2 - Review feedback on v1 indicated that more description was needed
> in the backport note. v2 corrects this. v1 also included
> a prerequisite commit 8c0cea59d40c ("net_sched: sch_sfq: use a temporary
> work area for validating configuration"). Upon further inspection,
> this was determined to be unneeded by the fix commit and was refactored
> out of the backport.
> 
> v3 - After v2 was submitted, an update to the Oracular kernel applied
> the fix commit. v3 removes the Oracular patch.
> 
> Octavian Purdila (1):
>   net_sched: sch_sfq: move the limit validation
> 
>  net/sched/sch_sfq.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> -- 
> 2.43.0
> 
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

The Jammy patch shouldn't be applied the same to Noble since Noble has a few
more relevant commits than Jammy. Namely, 10685681bafc ("net_sched: sch_sfq:
don't allow 1 packet limit") which introduces the limit validation for the
first time has to have its chunk removed from the file, otherwise you'll have
two copies of the limit validation (compare to the upstream fix for this CVE).
Noble also has e4650d7ae425 ("net_sched: sch_sfq: handle bigger packets") and
therefore the backport note is incorrect and the patch should include the call
to NL_SET_ERR_MSG_MOD().

As a secondary note:
Jammy does not have the break commit applied, which was also a CVE fix with its
own CVE number. Since this patch effectively replaces that one, you won't need
to apply the break commit, but the kernel will still be marked vulnerable for
the other CVE unless this commit is marked as a fix for it as well. The other
CVE is CVE-2024-57996. Please check with our security team about marking this
commit as a fix for that -- it might be as simple as adding that number to the
commit message during application to the tree.