ACK/Cmnt: [SRU][J/N][PATCH v4 0/1] CVE-2025-37752

[Ian Whitfield]

On Fri, Jul 11, 2025 at 06:28:19PM -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
> Noble:    backported from upstream
> 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.
> 
> v4 - Review of v3 revealed that the Noble patch was errantly removing
> the NL_SET_ERR_MSG_MOD() macro call.
> 
> 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

As mentioned in the previous version of this patchset, this fix also covers
CVE-2024-57996 for Jammy. CVE-2024-57996's fix commit is not applied to Jammy's
tree, so this kernel will still be marked vulnerable to CVE-2024-57996 even
though after this patchset is applied it will not be vulnerable. This might be
possible to fix with just adding CVE-2024-57996 to the commit message during
application or by adding a special rule for this in our CVE tracker. Please talk
to the security team or whoever is applying the patch about addressing this.

The Noble backport note shouldn't mention NL_SET_ERR_MSG_MOD() now that that
macro call is left unmodified. Including a mention of it in the note gives the
impression to the reader that there was a change from upstream in that regard,
but there was none.

Acked-by: Ian Whitfield <ian.whitfield at canonical.com>