deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-39756
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

fs: Prevent file descriptor table allocations exceeding INT_MAX

When sysctl_nr_open is set to a very high value (for example,[PII_REDACTED]
as set by systemd), processes attempting to use file descriptors near
the limit can trigger massive memory allocation attempts that exceed
INT_MAX, resulting in a WARNING in mm/slub.c:

  WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288

This happens because kvmalloc_array() and kvmalloc() check if the
requested size exceeds INT_MAX and emit a warning when the allocation is
not flagged with __GFP_NOWARN.

Specifically, when nr_open is set to[PII_REDACTED] (0x3ffffff8) and a
process calls dup2(oldfd,[PII_REDACTED]), the kernel attempts to allocate:
- File descriptor array:[PII_REDACTED] * 8 bytes = 8,589,935,040 bytes
- Multiple bitmaps: ~400MB
- Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)

Reproducer:
1. Set /proc/sys/fs/nr_open to[PII_REDACTED]:
   # echo[PII_REDACTED] > /proc/sys/fs/nr_open

2. Run a program that uses a high file descriptor:
   #include <unistd.h>
   #include <sys/resource.h>

   int main() {
       struct rlimit rlim = {[PII_REDACTED],[PII_REDACTED]};
       setrlimit(RLIMIT_NOFILE, &rlim);
       dup2(2,[PII_REDACTED]);  // Triggers the warning
       return 0;
   }

3. Observe WARNING in dmesg at mm/slub.c:5027

systemd commit a8b627a introduced automatic bumping of fs.nr_open to the
maximum possible value. The rationale was that systems with memory
control groups (memcg) no longer need separate file descriptor limits
since memory is properly accounted. However, this change overlooked
that:

1. The kernel's allocation functions still enforce INT_MAX as a maximum
   size regardless of memcg accounting
2. Programs and tests that legitimately test file descriptor limits can
   inadvertently trigger massive allocations
3. The resulting allocations (>8GB) are impractical and will always fail

systemd's algorithm starts with INT_MAX and keeps halving the value
until the kernel accepts it. On most systems, this results in nr_open
being set to[PII_REDACTED] (0x3ffffff8), which is just under 1GB of file
descriptors.

While processes rarely use file descriptors near this limit in normal
operation, certain selftests (like
tools/testing/selftests/core/unshare_test.c) and programs that test file
descriptor limits can trigger this issue.

Fix this by adding a check in alloc_fdtable() to ensure the requested
allocation size does not exceed INT_MAX. This causes the operation to
fail with -EMFILE instead of triggering a kernel warning and avoids the
impractical >8GB memory allocation request.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/04a2c4b4511d186b0fce685da21085a5d4acd370; https://git.kernel.org/stable/c/237e416eb62101f21b28c9e6e564d10efe1ecc6f; https://git.kernel.org/stable/c/628fc28f42d979f36dbf75a6129ac7730e30c04e
CVE: CVE-2025-39757
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Validate UAC3 cluster segment descriptors

UAC3 class segment descriptors need to be verified whether their sizes
match with the declared lengths and whether they fit with the
allocated buffer sizes, too.  Otherwise malicious firmware may lead to
the unexpected OOB accesses.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/1034719fdefd26caeec0a44a868bb5a412c2c1a5; https://git.kernel.org/stable/c/275e37532e8ebe25e8a4069b2d9f955bfd202a46; https://git.kernel.org/stable/c/47ab3d820cb0a502bd0074f83bb3cf7ab5d79902
CVE: CVE-2025-39758
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages

Ever since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"),
we have been doing this:

static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset,
                             size_t size)
[...]
        /* Calculate the number of bytes we need to push, for this page
         * specifically */
        size_t bytes = min_t(size_t, PAGE_SIZE - offset, size);
        /* If we can't splice it, then copy it in, as normal */
        if (!sendpage_ok(page[i]))
                msg.msg_flags &= ~MSG_SPLICE_PAGES;
        /* Set the bvec pointing to the page, with len $bytes */
        bvec_set_page(&bvec, page[i], bytes, offset);
        /* Set the iter to $size, aka the size of the whole sendpages (!!!) */
        iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, size);
try_page_again:
        lock_sock(sk);
        /* Sendmsg with $size size (!!!) */
        rv = tcp_sendmsg_locked(sk, &msg, size);

This means we've been sending oversized iov_iters and tcp_sendmsg calls
for a while. This has a been a benign bug because sendpage_ok() always
returned true. With the recent slab allocator changes being slowly
introduced into next (that disallow sendpage on large kmalloc
allocations), we have recently hit out-of-bounds crashes, due to slight
differences in iov_iter behavior between the MSG_SPLICE_PAGES and
"regular" copy paths:

(MSG_SPLICE_PAGES)
skb_splice_from_iter
  iov_iter_extract_pages
    iov_iter_extract_bvec_pages
      uses i->nr_segs to correctly stop in its tracks before OoB'ing everywhere
  skb_splice_from_iter gets a "short" read

(!MSG_SPLICE_PAGES)
skb_copy_to_page_nocache copy=iov_iter_count
 [...]
   copy_from_iter
        /* this doesn't help */
        if (unlikely(iter->count < len))
                len = iter->count;
          iterate_bvec
            ... and we run off the bvecs

Fix this by properly setting the iov_iter's byte count, plus sending the
correct byte count to tcp_sendmsg_locked.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/42ebc16d9d2563f1a1ce0f05b643ee68d54fabf8; https://git.kernel.org/stable/c/5661fdd218c2799001b88c17acd19f4395e4488e; https://git.kernel.org/stable/c/673cf582fd788af12cdacfb62a6a[PII_REDACTED]81
CVE: CVE-2025-39759
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: qgroup: fix race between quota disable and quota rescan ioctl

There's a race between a task disabling quotas and another running the
rescan ioctl that can result in a use-after-free of qgroup records from
the fs_info->qgroup_tree rbtree.

This happens as follows:

1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan();

2) Task B enters btrfs_quota_disable() and calls
   btrfs_qgroup_wait_for_completion(), which does nothing because at that
   point fs_info->qgroup_rescan_running is false (it wasn't set yet by
   task A);

3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups
   from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock;

4) Task A enters qgroup_rescan_zero_tracking() which starts iterating
   the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock,
   but task B is freeing qgroup records from that tree without holding
   the lock, resulting in a use-after-free.

Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config().
Also at btrfs_qgroup_rescan() don't start the rescan worker if quotas
were already disabled.
CVSS Score: 7.0 (HIGH)
CWE: CWE-362
References: https://git.kernel.org/stable/c/2fd0f5ceb997f90f4332ccbab6c7e907e6b2d0eb; https://git.kernel.org/stable/c/7cda0fdde5d[PII_REDACTED]421d207870500f9aace; https://git.kernel.org/stable/c/b172535ccba12f0cf7d23b3b840989de47fc104d
CVE: CVE-2025-39760
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: core: config: Prevent OOB read in SS endpoint companion parsing

usb_parse_ss_endpoint_companion() checks descriptor type before length,
enabling a potentially odd read outside of the buffer size.

Fix this up by checking the size first before looking at any of the
fields in the descriptor.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/058ad2b722812708fe[PII_REDACTED]4ae36563e33b; https://git.kernel.org/stable/c/4fe6f472f0beef4281e6f03bc38a910a33be663f; https://git.kernel.org/stable/c/5badd56c711e2c8371d1670f9bd[PII_REDACTED]23c
CVE: CVE-2025-39761
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Decrement TID on RX peer frag setup error handling

Currently, TID is not decremented before peer cleanup, during error
handling path of ath12k_dp_rx_peer_frag_setup(). This could lead to
out-of-bounds access in peer->rx_tid[].

Hence, add a decrement operation for TID, before peer cleanup to
ensures proper cleanup and prevents out-of-bounds access issues when
the RX peer frag setup fails.

Found during code review. Compile tested only.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/7c0884fcd2ddde0544d2e77f297ae461e1f53f58; https://git.kernel.org/stable/c/7c3e99fd4a66a5ac9c7dd32db07359666efe0002; https://git.kernel.org/stable/c/9530d666f4376c294cdf4348c29fe3542fec980a
CVE: CVE-2025-39762
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: add null check

[WHY]
Prevents null pointer dereferences to enhance function robustness

[HOW]
Adds early null check and return false if invalid.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/10d97cc1a14ef1f611e156b0b27e8b226e103cc2; https://git.kernel.org/stable/c/13895744e2c639324cf3cb18f2ba4e3f400dd0dd; https://git.kernel.org/stable/c/158b9201c17fc93ed4253c2f03b77fd2671669a1
CVE: CVE-2025-39763
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: APEI: send SIGBUS to current task if synchronous memory error not recovered

If a synchronous error is detected as a result of user-space process
triggering a 2-bit uncorrected error, the CPU will take a synchronous
error exception such as Synchronous External Abort (SEA) on Arm64. The
kernel will queue a memory_failure() work which poisons the related
page, unmaps the page, and then sends a SIGBUS to the process, so that
a system wide panic can be avoided.

However, no memory_failure() work will be queued when abnormal
synchronous errors occur. These errors can include situations like
invalid PA, unexpected severity, no memory failure config support,
invalid GUID section, etc. In such a case, the user-space process will
trigger SEA again.  This loop can potentially exceed the platform
firmware threshold or even trigger a kernel hard lockup, leading to a
system reboot.

Fix it by performing a force kill if no memory_failure() work is queued
for synchronous errors.

[ rjw: Changelog edits ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/082735fbcdb6cd0cf20fbec94516ab2996f1cdd5; https://git.kernel.org/stable/c/2fbc85da9ac9386bd89fcc94e0aadaea19d47784; https://git.kernel.org/stable/c/3cb4f[PII_REDACTED]b0f51d5300f8cb6c78f343ea
CVE: CVE-2025-39764
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: ctnetlink: remove refcounting in expectation dumpers

Same pattern as previous patch: do not keep the expectation object
alive via refcount, only store a cookie value and then use that
as the skip hint for dump resumption.

AFAICS this has the same issue as the one resolved in the conntrack
dumper, when we do
  if (!refcount_inc_not_zero(&exp->use))

to increment the refcount, there is a chance that exp == last, which
causes a double-increment of the refcount and subsequent memory leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/078d33c95bf534d37aa04269d1ae6158e20082d5; https://git.kernel.org/stable/c/1492e3dcb2be3aa46d1963da96aa9593e4e4db5a; https://git.kernel.org/stable/c/64b[PII_REDACTED]e3238464c66894e30ba30c7e851
CVE: CVE-2025-39765
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: timer: fix ida_free call while not allocated

In the snd_utimer_create() function, if the kasprintf() function return
NULL, snd_utimer_put_id() will be called, finally use ida_free()
to free the unallocated id 0.

the syzkaller reported the following information:
  ------------[ cut here ]------------
  ida_free called for id=0 which is not allocated.
  WARNING: CPU: 1 PID: 1286 at lib/idr.c:592 ida_free+0x1fd/0x2f0 lib/idr.c:592
  Modules linked in:
  CPU: 1 UID: 0 PID: 1286 Comm: syz-executor164 Not tainted 6.15.8 #3 PREEMPT(lazy)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
  RIP: 0010:ida_free+0x1fd/0x2f0 lib/idr.c:592
  Code: f8 fc 41 83 fc 3e 76 69 e8 70 b2 f8 (...)
  RSP: 0018:ffffc900007f79c8 EFLAGS: 00010282
  RAX: [PII_REDACTED] RBX: 1ffff920000fef3b RCX: ffffffff872176a5
  RDX: ffff88800369d200 RSI: [PII_REDACTED] RDI: ffff88800369d200
  RBP: [PII_REDACTED] R08: ffffffff87ba60a5 R09: [PII_REDACTED]
  R10: [PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
  R13: [PII_REDACTED] R14: [PII_REDACTED] R15: [PII_REDACTED]
  FS:  00007f6f1abc1740(0000) GS:ffff8880d76a0000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2: 00007f6f1ad7a784 CR3: 000000007a6e2000 CR4:[PII_REDACTED]0006f0
  Call Trace:
   <TASK>
   snd_utimer_put_id sound/core/timer.c:2043 [inline] [snd_timer]
   snd_utimer_create+0x59b/0x6a0 sound/core/timer.c:2184 [snd_timer]
   snd_utimer_ioctl_create sound/core/timer.c:2202 [inline] [snd_timer]
   __snd_timer_user_ioctl.isra.0+0x724/0x1340 sound/core/timer.c:2287 [snd_timer]
   snd_timer_user_ioctl+0x75/0xc0 sound/core/timer.c:2298 [snd_timer]
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:907 [inline]
   __se_sys_ioctl fs/ioctl.c:893 [inline]
   __x64_sys_ioctl+0x198/0x200 fs/ioctl.c:893
   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
   do_syscall_64+0x7b/0x160 arch/x86/entry/syscall_64.c:94
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  [...]

The utimer->id should be set properly before the kasprintf() function,
ensures the snd_utimer_put_id() function will free the allocated id.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/34327b362ce2849a5eb02f47e800049e7a20a0ba; https://git.kernel.org/stable/c/5003a65790ed66be882d1987cc2ca86af0de3db1; https://git.kernel.org/stable/c/af386b52531d14c4b20f11c452787b1b6dd4eb8d
CVE: CVE-2025-39766
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit

The following setup can trigger a WARNING in htb_activate due to
the condition: !cl->leaf.q->q.qlen

tc qdisc del dev lo root
tc qdisc add dev lo root handle 1: htb default 1
tc class add dev lo parent 1: classid 1:1 \
       htb rate 64bit
tc qdisc add dev lo parent 1:1 handle f: \
       cake memlimit 1b
ping -I lo -f -c1 -s64 -W0.001 127.0.0.1

This is because the low memlimit leads to a low buffer_limit, which
causes packet dropping. However, cake_enqueue still returns
NET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with an
empty child qdisc. We should return NET_XMIT_CN when packets are
dropped from the same tin and flow.

I do not believe return value of NET_XMIT_CN is necessary for packet
drops in the case of ack filtering, as that is meant to optimize
performance, not to signal congestion.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/0dacfc5372e314d1219f03e64dde3ab495a5a25e; https://git.kernel.org/stable/c/15de71d06a400f7fdc15bf377a2552b0ec437cf5; https://git.kernel.org/stable/c/62d591dde4defb1333d202410609c4ddeae060b3
CVE: CVE-2025-39768
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: HWS, fix complex rules rehash error flow

Moving rules from matcher to matcher should not fail.
However, if it does fail due to various reasons, the error flow
should allow the kernel to continue functioning (albeit with broken
steering rules) instead of going into series of soft lock-ups or
some other problematic behaviour.

Similar to the simple rules, complex rules rehash logic suffers
from the same problems. This patch fixes the error flow for moving
complex rules:
 - If new rule creation fails before it was even enqeued, do not
   poll for completion
 - If TIMEOUT happened while moving the rule, no point trying
   to poll for completions for other rules. Something is broken,
   completion won't come, just abort the rehash sequence.
 - If some other completion with error received, don't give up.
   Continue handling rest of the rules to minimize the damage.
 - Make sure that the first error code that was received will
   be actually returned to the caller instead of replacing it
   with the generic error code.

All the aforementioned issues stem from the same bad error flow,
so no point fixing them one by one and leaving partially broken
code - fixing them in one patch.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/37d54bc28d092bc3b314da45d730f00e9d86ec2a; https://git.kernel.org/stable/c/4a842b1bf18a32ee0c25dd6dd98728b786a76fe4
CVE: CVE-2025-39769
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: Fix lockdep warning during rmmod

The commit under the Fixes tag added a netdev_assert_locked() in
bnxt_free_ntp_fltrs().  The lock should be held during normal run-time
but the assert will be triggered (see below) during bnxt_remove_one()
which should not need the lock.  The netdev is already unregistered by
then.  Fix it by calling netdev_assert_locked_or_invisible() which will
not assert if the netdev is unregistered.

WARNING: CPU: 5 PID: 2241 at ./include/net/netdev_lock.h:17 bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en]
Modules linked in: rpcrdma rdma_cm iw_cm ib_cm configfs ib_core bnxt_en(-) bridge stp llc x86_pkg_temp_thermal xfs tg3 [last unloaded: bnxt_re]
CPU: 5 UID: 0 PID: 2241 Comm: rmmod Tainted: G S      W           6.16.0 #2 PREEMPT(voluntary)
Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017
RIP: 0010:bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en]
Code: 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 8b 47 60 be ff ff ff ff 48 8d b8 28 0c 00 00 e8 d0 cf 41 c3 85 c0 0f 85 2e ff ff ff <0f> 0b e9 27 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffa92082387da0 EFLAGS: 00010246
RAX: [PII_REDACTED] RBX: ffff9e5b593d8000 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: ffffffff83dc9a70 RDI: ffffffff83e1a1cf
RBP: ffff9e5b593d8c80 R08: [PII_REDACTED] R09: ffffffff8373a2b3
R10:[PII_REDACTED]00009f R11: [PII_REDACTED] R12: [PII_REDACTED]
R13: ffffffffc01c4478 R14: dead[PII_REDACTED]22 R15: dead[PII_REDACTED]00
FS:  00007f3a8a52c740(0000) GS:ffff9e631ad1c000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 000055bb289419c8 CR3:[PII_REDACTED]74e001 CR4:[PII_REDACTED]3706f0
Call Trace:
 <TASK>
 bnxt_remove_one+0x57/0x180 [bnxt_en]
 pci_device_remove+0x39/0xc0
 device_release_driver_internal+0xa5/0x130
 driver_detach+0x42/0x90
 bus_remove_driver+0x61/0xc0
 pci_unregister_driver+0x38/0x90
 bnxt_exit+0xc/0x7d0 [bnxt_en]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/4611d88a37cfc18cbabc6978aaf7325d1ae3f53a; https://git.kernel.org/stable/c/5885d39dce879fbbc953f40e19adb60c29802302
CVE: CVE-2025-39771
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

regulator: pca9450: Use devm_register_sys_off_handler

With module test, there is error dump:
------------[ cut here ]------------
  notifier callback pca9450_i2c_restart_handler already registered
  WARNING: kernel/notifier.c:23 at notifier_chain_register+0x5c/0x88,
  CPU#0: kworker/u16:3/50
  Call trace:
  notifier_chain_register+0x5c/0x88 (P)
  atomic_notifier_chain_register+0x30/0x58
  register_restart_handler+0x1c/0x28
  pca9450_i2c_probe+0x418/0x538
  i2c_device_probe+0x220/0x3d0
  really_probe+0x114/0x410
  __driver_probe_device+0xa0/0x150
  driver_probe_device+0x40/0x114
  __device_attach_driver+0xd4/0x12c

So use devm_register_sys_off_handler to let kernel handle the resource
free to avoid kernel dump.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/447be50598c05499f7ccc2b1f6ddb3da30f8099a; https://git.kernel.org/stable/c/7a8c8aa0b0b2c62a0232bf868def85f3069ba7a7
CVE: CVE-2025-39772
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/hisilicon/hibmc: fix the hibmc loaded failed bug

When hibmc loaded failed, the driver use hibmc_unload to free the
resource, but the mutexes in mode.config are not init, which will
access an NULL pointer. Just change goto statement to return, because
hibnc_hw_init() doesn't need to free anything.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/93a08f856fcc5aaeeecad01f71bef[PII_REDACTED]a; https://git.kernel.org/stable/c/a4f1b9c57092c48bdc7958abd23403ccaed437b2; https://git.kernel.org/stable/c/c950e1be3a24d021475b56efdb49daa7fbba63a9
CVE: CVE-2025-39773
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

net: bridge: fix soft lockup in br_multicast_query_expired()

When set multicast_query_interval to a large value, the local variable
'time' in br_multicast_send_query() may overflow. If the time is smaller
than jiffies, the timer will expire immediately, and then call mod_timer()
again, which creates a loop and may trigger the following soft lockup
issue.

  watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66]
  CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none)
  Call Trace:
   <IRQ>
   __netdev_alloc_skb+0x2e/0x3a0
   br_ip6_multicast_alloc_query+0x212/0x1b70
   __br_multicast_send_query+0x376/0xac0
   br_multicast_send_query+0x299/0x510
   br_multicast_query_expired.constprop.0+0x16d/0x1b0
   call_timer_fn+0x3b/0x2a0
   __run_timers+0x619/0x950
   run_timer_softirq+0x11c/0x220
   handle_softirqs+0x18e/0x560
   __irq_exit_rcu+0x158/0x1a0
   sysvec_apic_timer_interrupt+0x76/0x90
   </IRQ>

This issue can be reproduced with:
  ip link add br0 type bridge
  echo 1 > /sys/class/net/br0/bridge/multicast_querier
  echo 0xffffffffffffffff >
  	/sys/class/net/br0/bridge/multicast_query_interval
  ip link set dev br0 up

The multicast_startup_query_interval can also cause this issue. Similar to
the commit 99b40610956a ("net: bridge: mcast: add and enforce query
interval minimum"), add check for the query interval maximum to fix this
issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/34171b9e53bd1dc264f5556579f2b04f04435c73; https://git.kernel.org/stable/c/43e281fde5e76a866a4d10780c35023f16c0e432; https://git.kernel.org/stable/c/5bf5fce8a0c2a70d063af778fdb5b27238174cdd
CVE: CVE-2025-39774
Published: 2025-09-11
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: adc: rzg2l_adc: Set driver data before enabling runtime PM

When stress-testing the system by repeatedly unbinding and binding the ADC
device in a loop, and the ADC is a supplier for another device (e.g., a
thermal hardware block that reads temperature through the ADC), it may
happen that the ADC device is runtime-resumed immediately after runtime PM
is enabled, triggered by its consumer. At this point, since drvdata is not
yet set and the driver's runtime PM callbacks rely on it, a crash can
occur. To avoid this, set drvdata just after it was allocated.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/c69e13965f26b8058f538ea8bdbd2d7718cf1fbe; https://git.kernel.org/stable/c/e7ce902db071a7b3e696a43d6e14ca57360deee6