GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
oesa-2025-1162
Vulnerability from osv_openeuler
Published
2025-02-21 11:08
Modified
2026-08-06 11:08
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

ila: call nf_unregister_net_hooks() sooner

syzbot found an use-after-free Read in ila_nf_input [1]

Issue here is that ila_xlat_exit_net() frees the rhashtable, then call nf_unregister_net_hooks().

It should be done in the reverse way, with a synchronize_rcu().

This is a good match for a pre_exit() method.

[1] BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline] BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline] BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16

CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup include/linux/rhashtable.h:604 [inline] rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6108 __napi_poll+0xcb/0x490 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6963 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:928 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620 flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) page_type: 0xbfffffff(buddy) raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000 raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493 prep_new_page mm/page_alloc.c:1501 [inline] get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline] alloc_pages_node_noprof include/linux/gfp.h:296 [inline] kmalloclarge_node+0x8b/0x1d0 mm/slub.c:4103 kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130 __do_kmalloc_node mm/slub.c:4146 [inline] __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164 __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650 bucket_table_alloc lib/rhashtable.c:186 [inline] rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071 ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613 ops_ini ---truncated---(CVE-2024-46782)

In the Linux kernel, the following vulnerability has been resolved:

drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error

Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access.

dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.(CVE-2024-47697)

In the Linux kernel, the following vulnerability has been resolved:

nvme-rdma: unquiesce admin_q before destroy it

Kernel will hang on destroy admin_q while we create ctrl failed, such as following calltrace:

PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362 #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b

This due to we have quiesced admi_q before cancel requests, but forgot to unquiesce before destroy it, as a result we fail to drain the pending requests, and hang on blk_mq_freeze_queue_wait() forever. Here try to reuse nvme_rdma_teardown_admin_queue() to fix this issue and simplify the code.(CVE-2024-49569)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: SCO: Fix UAF on sco_sock_timeout

conn->sk maybe have been unlinked/freed while waiting for sco_conn_lock so this checks if the conn->sk is still valid by checking if it part of sco_sk_list.(CVE-2024-50125)

In the Linux kernel, the following vulnerability has been resolved:

usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()

The "*cmd" variable can be controlled by the user via debugfs. That means "new_cam" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30).

The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()(CVE-2024-50268)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT

In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer.

In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT).

In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop.

net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)(CVE-2024-53057)

In the Linux kernel, the following vulnerability has been resolved:

mm: resolve faulty mmap_region() error path behaviour

The mmap_region() function is somewhat terrifying, with spaghetti-like control flow and numerous means by which issues can arise and incomplete state, memory leaks and other unpleasantness can occur.

A large amount of the complexity arises from trying to handle errors late in the process of mapping a VMA, which forms the basis of recently observed issues with resource leaks and observable inconsistent state.

Taking advantage of previous patches in this series we move a number of checks earlier in the code, simplifying things by moving the core of the logic into a static internal function __mmap_region().

Doing this allows us to perform a number of checks up front before we do any real work, and allows us to unwind the writable unmap check unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE validation unconditionally also.

We move a number of things here:

  1. We preallocate memory for the iterator before we call the file-backed memory hook, allowing us to exit early and avoid having to perform complicated and error-prone close/free logic. We carefully free iterator state on both success and error paths.

  2. The enclosing mmap_region() function handles the mapping_map_writable() logic early. Previously the logic had the mapping_map_writable() at the point of mapping a newly allocated file-backed VMA, and a matching mapping_unmap_writable() on success and error paths.

We now do this unconditionally if this is a file-backed, shared writable mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however doing so does not invalidate the seal check we just performed, and we in any case always decrement the counter in the wrapper.

We perform a debug assert to ensure a driver does not attempt to do the opposite.

  1. We also move arch_validate_flags() up into the mmap_region() function. This is only relevant on arm64 and sparc64, and the check is only meaningful for SPARC with ADI enabled. We explicitly add a warning for this arch if a driver invalidates this check, though the code ought eventually to be fixed to eliminate the need for this.

With all of these measures in place, we no longer need to explicitly close the VMA on error paths, as we place all checks which might fail prior to a call to any driver mmap hook.

This eliminates an entire class of errors, makes the code easier to reason about and more robust.(CVE-2024-53096)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ipset: add missing range check in bitmap_ip_uadt

When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs.

So we should add missing range checks and remove unnecessary range checks.(CVE-2024-53141)

In the Linux kernel, the following vulnerability has been resolved:

comedi: Flush partial mappings in error case

If some remap_pfn_range() calls succeeded before one failed, we still have buffer pages mapped into the userspace page tables when we drop the buffer reference with comedi_buf_map_put(bm). The userspace mappings are only cleaned up later in the mmap error path.

Fix it by explicitly flushing all mappings in our VMA on the error path.

See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in error case").(CVE-2024-53148)

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()

I found the following bug in my fuzzer:

UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <TASK> dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ...

Since this bug has been confirmed to be caused by insufficient verification of conn_rsp_epid, I think it would be appropriate to add a range check for conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.(CVE-2024-53156)

In the Linux kernel, the following vulnerability has been resolved:

net: inet6: do not leave a dangling sk pointer in inet6_create()

sock_init_data() attaches the allocated sk pointer to the provided sock object. If inet6_create() fails later, the sk object is released, but the sock object retains the dangling sk pointer, which may cause use-after-free later.

Clear the sock sk pointer on error.(CVE-2024-56600)

In the Linux kernel, the following vulnerability has been resolved:

net: inet: do not leave a dangling sk pointer in inet_create()

sock_init_data() attaches the allocated sk object to the provided sock object. If inet_create() fails later, the sk object is freed, but the sock object retains the dangling pointer, which may create use-after-free later.

Clear the sk pointer in the sock object on error.(CVE-2024-56601)

In the Linux kernel, the following vulnerability has been resolved:

gpio: grgpio: Add NULL check in grgpio_probe

devm_kasprintf() can return a NULL pointer on failure,but this returned value in grgpio_probe is not checked. Add NULL check in grgpio_probe, to handle kernel NULL pointer dereference error.(CVE-2024-56634)

In the Linux kernel, the following vulnerability has been resolved:

s390/cpum_sf: Handle CPU hotplug remove during sampling

CPU hotplug remove handling triggers the following function call sequence:

CPUHP_AP_PERF_S390_SF_ONLINE --> s390_pmu_sf_offline_cpu() ... CPUHP_AP_PERF_ONLINE --> perf_event_exit_cpu()

The s390 CPUMF sampling CPU hotplug handler invokes:

s390_pmu_sf_offline_cpu() +--> cpusf_pmu_setup() +--> setup_pmc_cpu() +--> deallocate_buffers()

This function de-allocates all sampling data buffers (SDBs) allocated for that CPU at event initialization. It also clears the PMU_F_RESERVED bit. The CPU is gone and can not be sampled.

With the event still being active on the removed CPU, the CPU event hotplug support in kernel performance subsystem triggers the following function calls on the removed CPU:

perf_event_exit_cpu() +--> perf_event_exit_cpu_context() +--> __perf_event_exit_context() +--> __perf_remove_from_context() +--> event_sched_out() +--> cpumsf_pmu_del() +--> cpumsf_pmu_stop() +--> hw_perf_event_update()

to stop and remove the event. During removal of the event, the sampling device driver tries to read out the remaining samples from the sample data buffers (SDBs). But they have already been freed (and may have been re-assigned). This may lead to a use after free situation in which case the samples are most likely invalid. In the best case the memory has not been reassigned and still contains valid data.

Remedy this situation and check if the CPU is still in reserved state (bit PMU_F_RESERVED set). In this case the SDBs have not been released an contain valid data. This is always the case when the event is removed (and no CPU hotplug off occured). If the PMU_F_RESERVED bit is not set, the SDB buffers are gone.(CVE-2024-57849)

In the Linux kernel, the following vulnerability has been resolved:

ila: serialize calls to nf_register_net_hooks()

syzbot found a race in ila_add_mapping() [1]

commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner") attempted to fix a similar issue.

Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.

Add a mutex to make sure at most one thread is calling nf_register_net_hooks().

[1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501

CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626 nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785 process_backlog+0x443/0x15f0 net/core/dev.c:6117 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0xa94/0x1010 net/core/dev.c:7074 handle_softirqs+0x213/0x8f0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049(CVE-2024-57900)

In the Linux kernel, the following vulnerability has been resolved:

sched: sch_cake: add bounds checks to host bulk flow fairness counts

Even though we fixed a logic error in the commit cited below, syzbot still managed to trigger an underflow of the per-host bulk flow counters, leading to an out of bounds memory access.

To avoid any such logic errors causing out of bounds memory accesses, this commit factors out all accesses to the per-host bulk flow counters to a series of helpers that perform bounds-checking before any increments and decrements. This also has the benefit of improving readability by moving the conditional checks for the flow mode into these helpers, instead of having them spread out throughout the code (which was the cause of the original logic error).

As part of this change, the flow quantum calculation is consolidated into a helper function, which means that the dithering applied to the ost load scaling is now applied both in the DRR rotation and when a sparse flow's quantum is first initiated. The only user-visible effect of this is that the maximum packet size that can be sent while a flow stays sparse will now vary with +/- one byte in some cases. This should not make a noticeable difference in practice, and thus it's not worth complicating the code to preserve the old behaviour.(CVE-2025-21647)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: conntrack: clamp maximum hashtable size to INT_MAX

Use INT_MAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset. See:

0708a0afe291 ("mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls")

Note: hashtable resize is only possible from init_netns.(CVE-2025-21648)

In the Linux kernel, the following vulnerability has been resolved:

iomap: avoid avoid truncating 64-bit offset to 32 bits

on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a 32-bit position due to folio_next_index() returning an unsigned long. This could lead to an infinite loop when writing to an xfs filesystem.(CVE-2025-21667)

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-250.0.0.153.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-250.0.0.153.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-250.0.0.153.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-250.0.0.153.oe2203sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nila: call nf_unregister_net_hooks() sooner\n\nsyzbot found an use-after-free Read in ila_nf_input [1]\n\nIssue here is that ila_xlat_exit_net() frees the rhashtable,\nthen call nf_unregister_net_hooks().\n\nIt should be done in the reverse way, with a synchronize_rcu().\n\nThis is a good match for a pre_exit() method.\n\n[1]\n BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]\n BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]\n BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]\n BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672\nRead of size 4 at addr ffff888064620008 by task ksoftirqd/0/16\n\nCPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:93 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119\n  print_address_description mm/kasan/report.c:377 [inline]\n  print_report+0x169/0x550 mm/kasan/report.c:488\n  kasan_report+0x143/0x180 mm/kasan/report.c:601\n  rht_key_hashfn include/linux/rhashtable.h:159 [inline]\n  __rhashtable_lookup include/linux/rhashtable.h:604 [inline]\n  rhashtable_lookup include/linux/rhashtable.h:646 [inline]\n  rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672\n  ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]\n  ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]\n  ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190\n  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626\n  nf_hook include/linux/netfilter.h:269 [inline]\n  NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312\n  __netif_receive_skb_one_core net/core/dev.c:5661 [inline]\n  __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775\n  process_backlog+0x662/0x15b0 net/core/dev.c:6108\n  __napi_poll+0xcb/0x490 net/core/dev.c:6772\n  napi_poll net/core/dev.c:6841 [inline]\n  net_rx_action+0x89b/0x1240 net/core/dev.c:6963\n  handle_softirqs+0x2c4/0x970 kernel/softirq.c:554\n  run_ksoftirqd+0xca/0x130 kernel/softirq.c:928\n  smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164\n  kthread+0x2f0/0x390 kernel/kthread.c:389\n  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\n\nThe buggy address belongs to the physical page:\npage: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620\nflags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)\npage_type: 0xbfffffff(buddy)\nraw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000\nraw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000\npage dumped because: kasan: bad access detected\npage_owner tracks the page as freed\npage last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187\n  set_page_owner include/linux/page_owner.h:32 [inline]\n  post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493\n  prep_new_page mm/page_alloc.c:1501 [inline]\n  get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439\n  __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695\n  __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]\n  alloc_pages_node_noprof include/linux/gfp.h:296 [inline]\n  ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103\n  __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130\n  __do_kmalloc_node mm/slub.c:4146 [inline]\n  __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164\n  __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650\n  bucket_table_alloc lib/rhashtable.c:186 [inline]\n  rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071\n  ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613\n  ops_ini\n---truncated---(CVE-2024-46782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error\n\nEnsure index in rtl2830_pid_filter does not exceed 31 to prevent\nout-of-bounds access.\n\ndev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should\nonly operate on indices from 0 to 31. If index is 32, it will attempt to\naccess a non-existent 33rd bit, leading to out-of-bounds access.\nChange the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this\nissue.(CVE-2024-47697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-rdma: unquiesce admin_q before destroy it\n\nKernel will hang on destroy admin_q while we create ctrl failed, such\nas following calltrace:\n\nPID: 23644    TASK: ff2d52b40f439fc0  CPU: 2    COMMAND: \u0026quot;nvme\u0026quot;\n #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15\n #1 [ff61d23de260fc08] schedule at ffffffff8323c014\n #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1\n #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a\n #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006\n #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce\n #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced\n #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b\n #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362\n #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25\n    RIP: 00007fda7891d574  RSP: 00007ffe2ef06958  RFLAGS: 00000202\n    RAX: ffffffffffffffda  RBX: 000055e8122a4d90  RCX: 00007fda7891d574\n    RDX: 000000000000012b  RSI: 000055e8122a4d90  RDI: 0000000000000004\n    RBP: 00007ffe2ef079c0   R8: 000000000000012b   R9: 000055e8122a4d90\n    R10: 0000000000000000  R11: 0000000000000202  R12: 0000000000000004\n    R13: 000055e8122923c0  R14: 000000000000012b  R15: 00007fda78a54500\n    ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b\n\nThis due to we have quiesced admi_q before cancel requests, but forgot\nto unquiesce before destroy it, as a result we fail to drain the\npending requests, and hang on blk_mq_freeze_queue_wait() forever. Here\ntry to reuse nvme_rdma_teardown_admin_queue() to fix this issue and\nsimplify the code.(CVE-2024-49569)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: SCO: Fix UAF on sco_sock_timeout\n\nconn-\u0026gt;sk maybe have been unlinked/freed while waiting for sco_conn_lock\nso this checks if the conn-\u0026gt;sk is still valid by checking if it part of\nsco_sk_list.(CVE-2024-50125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()\n\nThe \u0026quot;*cmd\u0026quot; variable can be controlled by the user via debugfs.  That means\n\u0026quot;new_cam\u0026quot; can be as high as 255 while the size of the uc-\u0026gt;updated[] array\nis UCSI_MAX_ALTMODES (30).\n\nThe call tree is:\nucsi_cmd() // val comes from simple_attr_write_xsigned()\n-\u0026gt; ucsi_send_command()\n   -\u0026gt; ucsi_send_command_common()\n      -\u0026gt; ucsi_run_command() // calls ucsi-\u0026gt;ops-\u0026gt;sync_control()\n         -\u0026gt; ucsi_ccg_sync_control()(CVE-2024-50268)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT\n\nIn qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed\nto be either root or ingress. This assumption is bogus since it\u0026apos;s valid\nto create egress qdiscs with major handle ffff:\nBudimir Markovic found that for qdiscs like DRR that maintain an active\nclass list, it will cause a UAF with a dangling class pointer.\n\nIn 066a3b5b2346, the concern was to avoid iterating over the ingress\nqdisc since its parent is itself. The proper fix is to stop when parent\nTC_H_ROOT is reached because the only way to retrieve ingress is when a\nhierarchy which does not contain a ffff: major handle call into\nqdisc_lookup with TC_H_MAJ(TC_H_ROOT).\n\nIn the scenario where major ffff: is an egress qdisc in any of the tree\nlevels, the updates will also propagate to TC_H_ROOT, which then the\niteration must stop.\n\n\n net/sched/sch_api.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)(CVE-2024-53057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: resolve faulty mmap_region() error path behaviour\n\nThe mmap_region() function is somewhat terrifying, with spaghetti-like\ncontrol flow and numerous means by which issues can arise and incomplete\nstate, memory leaks and other unpleasantness can occur.\n\nA large amount of the complexity arises from trying to handle errors late\nin the process of mapping a VMA, which forms the basis of recently\nobserved issues with resource leaks and observable inconsistent state.\n\nTaking advantage of previous patches in this series we move a number of\nchecks earlier in the code, simplifying things by moving the core of the\nlogic into a static internal function __mmap_region().\n\nDoing this allows us to perform a number of checks up front before we do\nany real work, and allows us to unwind the writable unmap check\nunconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE\nvalidation unconditionally also.\n\nWe move a number of things here:\n\n1. We preallocate memory for the iterator before we call the file-backed\n   memory hook, allowing us to exit early and avoid having to perform\n   complicated and error-prone close/free logic. We carefully free\n   iterator state on both success and error paths.\n\n2. The enclosing mmap_region() function handles the mapping_map_writable()\n   logic early. Previously the logic had the mapping_map_writable() at the\n   point of mapping a newly allocated file-backed VMA, and a matching\n   mapping_unmap_writable() on success and error paths.\n\n   We now do this unconditionally if this is a file-backed, shared writable\n   mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however\n   doing so does not invalidate the seal check we just performed, and we in\n   any case always decrement the counter in the wrapper.\n\n   We perform a debug assert to ensure a driver does not attempt to do the\n   opposite.\n\n3. We also move arch_validate_flags() up into the mmap_region()\n   function. This is only relevant on arm64 and sparc64, and the check is\n   only meaningful for SPARC with ADI enabled. We explicitly add a warning\n   for this arch if a driver invalidates this check, though the code ought\n   eventually to be fixed to eliminate the need for this.\n\nWith all of these measures in place, we no longer need to explicitly close\nthe VMA on error paths, as we place all checks which might fail prior to a\ncall to any driver mmap hook.\n\nThis eliminates an entire class of errors, makes the code easier to reason\nabout and more robust.(CVE-2024-53096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: add missing range check in bitmap_ip_uadt\n\nWhen tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,\nthe values of ip and ip_to are slightly swapped. Therefore, the range check\nfor ip should be done later, but this part is missing and it seems that the\nvulnerability occurs.\n\nSo we should add missing range checks and remove unnecessary range checks.(CVE-2024-53141)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: Flush partial mappings in error case\n\nIf some remap_pfn_range() calls succeeded before one failed, we still have\nbuffer pages mapped into the userspace page tables when we drop the buffer\nreference with comedi_buf_map_put(bm). The userspace mappings are only\ncleaned up later in the mmap error path.\n\nFix it by explicitly flushing all mappings in our VMA on the error path.\n\nSee commit 79a61cc3fc04 (\u0026quot;mm: avoid leaving partial pfn mappings around in\nerror case\u0026quot;).(CVE-2024-53148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()\n\nI found the following bug in my fuzzer:\n\n  UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51\n  index 255 is out of range for type \u0026apos;htc_endpoint [22]\u0026apos;\n  CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n  Workqueue: events request_firmware_work_func\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x180/0x1b0\n   __ubsan_handle_out_of_bounds+0xd4/0x130\n   htc_issue_send.constprop.0+0x20c/0x230\n   ? _raw_spin_unlock_irqrestore+0x3c/0x70\n   ath9k_wmi_cmd+0x41d/0x610\n   ? mark_held_locks+0x9f/0xe0\n   ...\n\nSince this bug has been confirmed to be caused by insufficient verification\nof conn_rsp_epid, I think it would be appropriate to add a range check for\nconn_rsp_epid to htc_connect_service() to prevent the bug from occurring.(CVE-2024-53156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: inet6: do not leave a dangling sk pointer in inet6_create()\n\nsock_init_data() attaches the allocated sk pointer to the provided sock\nobject. If inet6_create() fails later, the sk object is released, but the\nsock object retains the dangling sk pointer, which may cause use-after-free\nlater.\n\nClear the sock sk pointer on error.(CVE-2024-56600)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: inet: do not leave a dangling sk pointer in inet_create()\n\nsock_init_data() attaches the allocated sk object to the provided sock\nobject. If inet_create() fails later, the sk object is freed, but the\nsock object retains the dangling pointer, which may create use-after-free\nlater.\n\nClear the sk pointer in the sock object on error.(CVE-2024-56601)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpio: grgpio: Add NULL check in grgpio_probe\n\ndevm_kasprintf() can return a NULL pointer on failure,but this\nreturned value in grgpio_probe is not checked.\nAdd NULL check in grgpio_probe, to handle kernel NULL\npointer dereference error.(CVE-2024-56634)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/cpum_sf: Handle CPU hotplug remove during sampling\n\nCPU hotplug remove handling triggers the following function\ncall sequence:\n\n   CPUHP_AP_PERF_S390_SF_ONLINE  --\u0026gt; s390_pmu_sf_offline_cpu()\n   ...\n   CPUHP_AP_PERF_ONLINE          --\u0026gt; perf_event_exit_cpu()\n\nThe s390 CPUMF sampling CPU hotplug handler invokes:\n\n s390_pmu_sf_offline_cpu()\n +--\u0026gt;  cpusf_pmu_setup()\n       +--\u0026gt; setup_pmc_cpu()\n            +--\u0026gt; deallocate_buffers()\n\nThis function de-allocates all sampling data buffers (SDBs) allocated\nfor that CPU at event initialization. It also clears the\nPMU_F_RESERVED bit. The CPU is gone and can not be sampled.\n\nWith the event still being active on the removed CPU, the CPU event\nhotplug support in kernel performance subsystem triggers the\nfollowing function calls on the removed CPU:\n\n  perf_event_exit_cpu()\n  +--\u0026gt; perf_event_exit_cpu_context()\n       +--\u0026gt; __perf_event_exit_context()\n\t    +--\u0026gt; __perf_remove_from_context()\n\t         +--\u0026gt; event_sched_out()\n\t              +--\u0026gt; cpumsf_pmu_del()\n\t                   +--\u0026gt; cpumsf_pmu_stop()\n                                +--\u0026gt; hw_perf_event_update()\n\nto stop and remove the event. During removal of the event, the\nsampling device driver tries to read out the remaining samples from\nthe sample data buffers (SDBs). But they have already been freed\n(and may have been re-assigned). This may lead to a use after free\nsituation in which case the samples are most likely invalid. In the\nbest case the memory has not been reassigned and still contains\nvalid data.\n\nRemedy this situation and check if the CPU is still in reserved\nstate (bit PMU_F_RESERVED set). In this case the SDBs have not been\nreleased an contain valid data. This is always the case when\nthe event is removed (and no CPU hotplug off occured).\nIf the PMU_F_RESERVED bit is not set, the SDB buffers are gone.(CVE-2024-57849)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nila: serialize calls to nf_register_net_hooks()\n\nsyzbot found a race in ila_add_mapping() [1]\n\ncommit 031ae72825ce (\u0026quot;ila: call nf_unregister_net_hooks() sooner\u0026quot;)\nattempted to fix a similar issue.\n\nLooking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.\n\nAdd a mutex to make sure at most one thread is calling nf_register_net_hooks().\n\n[1]\n BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]\n BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604\nRead of size 4 at addr ffff888028f40008 by task dhcpcd/5501\n\nCPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n  __dump_stack lib/dump_stack.c:94 [inline]\n  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n  print_address_description mm/kasan/report.c:378 [inline]\n  print_report+0xc3/0x620 mm/kasan/report.c:489\n  kasan_report+0xd9/0x110 mm/kasan/report.c:602\n  rht_key_hashfn include/linux/rhashtable.h:159 [inline]\n  __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604\n  rhashtable_lookup include/linux/rhashtable.h:646 [inline]\n  rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]\n  ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline]\n  ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]\n  ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185\n  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n  nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626\n  nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269\n  NF_HOOK include/linux/netfilter.h:312 [inline]\n  ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309\n  __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672\n  __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785\n  process_backlog+0x443/0x15f0 net/core/dev.c:6117\n  __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883\n  napi_poll net/core/dev.c:6952 [inline]\n  net_rx_action+0xa94/0x1010 net/core/dev.c:7074\n  handle_softirqs+0x213/0x8f0 kernel/softirq.c:561\n  __do_softirq kernel/softirq.c:595 [inline]\n  invoke_softirq kernel/softirq.c:435 [inline]\n  __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662\n  irq_exit_rcu+0x9/0x30 kernel/softirq.c:678\n  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]\n  sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049(CVE-2024-57900)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: sch_cake: add bounds checks to host bulk flow fairness counts\n\nEven though we fixed a logic error in the commit cited below, syzbot\nstill managed to trigger an underflow of the per-host bulk flow\ncounters, leading to an out of bounds memory access.\n\nTo avoid any such logic errors causing out of bounds memory accesses,\nthis commit factors out all accesses to the per-host bulk flow counters\nto a series of helpers that perform bounds-checking before any\nincrements and decrements. This also has the benefit of improving\nreadability by moving the conditional checks for the flow mode into\nthese helpers, instead of having them spread out throughout the\ncode (which was the cause of the original logic error).\n\nAs part of this change, the flow quantum calculation is consolidated\ninto a helper function, which means that the dithering applied to the\nost load scaling is now applied both in the DRR rotation and when a\nsparse flow\u0026apos;s quantum is first initiated. The only user-visible effect\nof this is that the maximum packet size that can be sent while a flow\nstays sparse will now vary with +/- one byte in some cases. This should\nnot make a noticeable difference in practice, and thus it\u0026apos;s not worth\ncomplicating the code to preserve the old behaviour.(CVE-2025-21647)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: clamp maximum hashtable size to INT_MAX\n\nUse INT_MAX as maximum size for the conntrack hashtable. Otherwise, it\nis possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when\nresizing hashtable because __GFP_NOWARN is unset. See:\n\n  0708a0afe291 (\u0026quot;mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls\u0026quot;)\n\nNote: hashtable resize is only possible from init_netns.(CVE-2025-21648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niomap: avoid avoid truncating 64-bit offset to 32 bits\n\non 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a\n32-bit position due to folio_next_index() returning an unsigned long.\nThis could lead to an infinite loop when writing to an xfs filesystem.(CVE-2025-21667)",
  "id": "OESA-2025-1162",
  "modified": "2026-08-06T11:08:15Z",
  "published": "2025-02-21T11:08:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1162"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46782"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47697"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49569"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50125"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50268"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53057"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53096"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53141"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53148"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53156"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56600"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56601"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56634"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57849"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57900"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21647"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21648"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21667"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-46782",
    "CVE-2024-47697",
    "CVE-2024-49569",
    "CVE-2024-50125",
    "CVE-2024-50268",
    "CVE-2024-53057",
    "CVE-2024-53096",
    "CVE-2024-53141",
    "CVE-2024-53148",
    "CVE-2024-53156",
    "CVE-2024-56600",
    "CVE-2024-56601",
    "CVE-2024-56634",
    "CVE-2024-57849",
    "CVE-2024-57900",
    "CVE-2025-21647",
    "CVE-2025-21648",
    "CVE-2025-21667"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.