GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2024-1520 (CVE-2024-25739)

Vulnerability from osv_openeuler – Published: 2024-05-10 11:06 – Updated: 2026-08-06 11:06 – Source website
VLAI
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

create_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi->leb_size.(CVE-2024-25739)

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

drm/bridge: sii902x: Fix probing race issue

A null pointer dereference crash has been observed rarely on TI platforms using sii9022 bridge:

[ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x] [ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x] [ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm] [ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper] [ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper] [ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm] [ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper] [ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper] [ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper] [ 53.326401] drm_client_register+0x5c/0xa0 [drm] [ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper] [ 53.336881] tidss_probe+0x128/0x264 [tidss] [ 53.341174] platform_probe+0x68/0xc4 [ 53.344841] really_probe+0x188/0x3c4 [ 53.348501] __driver_probe_device+0x7c/0x16c [ 53.352854] driver_probe_device+0x3c/0x10c [ 53.357033] __device_attach_driver+0xbc/0x158 [ 53.361472] bus_for_each_drv+0x88/0xe8 [ 53.365303] __device_attach+0xa0/0x1b4 [ 53.369135] device_initial_probe+0x14/0x20 [ 53.373314] bus_probe_device+0xb0/0xb4 [ 53.377145] deferred_probe_work_func+0xcc/0x124 [ 53.381757] process_one_work+0x1f0/0x518 [ 53.385770] worker_thread+0x1e8/0x3dc [ 53.389519] kthread+0x11c/0x120 [ 53.392750] ret_from_fork+0x10/0x20

The issue here is as follows:

  • tidss probes, but is deferred as sii902x is still missing.
  • sii902x starts probing and enters sii902x_init().
  • sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from DRM's perspective.
  • sii902x calls sii902x_audio_codec_init() and platform_device_register_data()
  • The registration of the audio platform device causes probing of the deferred devices.
  • tidss probes, which eventually causes sii902x_bridge_get_edid() to be called.
  • sii902x_bridge_get_edid() tries to use the i2c to read the edid. However, the sii902x driver has not set up the i2c part yet, leading to the crash.

Fix this by moving the drm_bridge_add() to the end of the sii902x_init(), which is also at the very end of sii902x_probe().(CVE-2024-26607)

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

tcp: make sure init the accept_queue's spinlocks once

When I run syz's reproduction C program locally, it causes the following issue: pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0! WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000 R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Call Trace: <IRQ> _raw_spin_unlock (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321) inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358) tcp_check_req (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234) __netif_receive_skb_one_core (net/core/dev.c:5529) process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533) net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:381) __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469) tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968) release_sock (net/core/sock.c:3536) inet_wait_for_connect (net/ipv4/af_inet.c:609) __inet_stream_connect (net/ipv4/af_inet.c:702) inet_stream_connect (net/ipv4/af_inet.c:748) __sys_connect (./include/linux/file.h:45 net/socket.c:2064) __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070) do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP: 0033:0x7fa10ff05a3d Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640 R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20 </TASK>

The issue triggering process is analyzed as follows: Thread A Thread B tcp_v4_rcv //receive ack TCP packet inet_shutdown tcp_check_req tcp_disconnect //disconnect sock ... tcp_set_state(sk, TCP_CLOSE) inet_csk_complete_hashdance ... inet_csk_reqsk_queue_add
---truncated---(CVE-2024-26614)

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

btrfs: don't abort filesystem when attempting to snapshot deleted subvolume

If the source file descriptor to the snapshot ioctl refers to a deleted subvolume, we get the following abort:

BTRFS: Transaction aborted (error -2) WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs] Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs] RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027 RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840 RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998 R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80 FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0 Call Trace: <TASK> ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? __warn+0x81/0x130 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? report_bug+0x171/0x1a0 ? handle_bug+0x3a/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? create_pending_snapshot+0x1040/0x1190 [btrfs] create_pending_snapshots+0x92/0xc0 [btrfs] btrfs_commit_transaction+0x66b/0xf40 [btrfs] btrfs_mksubvol+0x301/0x4d0 [btrfs] btrfs_mksnapshot+0x80/0xb0 [btrfs] __btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs] btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs] btrfs_ioctl+0x8a6/0x2650 [btrfs] ? kmem_cache_free+0x22/0x340 ? do_sys_openat2+0x97/0xe0 __x64_sys_ioctl+0x97/0xd0 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7fe20abe83af RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58 </TASK> ---[ end trace 0000000000000000 ]--- BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry BTRFS info (device vdc: state EA): forced readonly BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction. BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry

This happens because create_pending_snapshot() initializes the new root item as a copy of the source root item. This includes the refs field, which is 0 for a deleted subvolume. The call to btrfs_insert_root() therefore inserts a root with refs == 0. btrfs_get_new_fs_root() then finds the root and returns -ENOENT if refs == 0, which causes create_pending_snapshot() to abort.

Fix it by checking the source root's refs before attempting the snapshot, but after locking subvol_sem to avoid racing with deletion.(CVE-2024-26644)

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

hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove

In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the VMBus channel"), napi_disable was getting called for all channels, including all subchannels without confirming if they are enabled or not.

This caused hv_netvsc getting hung at napi_disable, when netvsc_probe() has finished running but nvdev->subchan_work has not started yet. netvsc_subchan_work() -> rndis_set_subchannel() has not created the sub-channels and because of that netvsc_sc_open() is not running. netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which netvsc_subchan_work did not run.

netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the opposite.

Now during netvsc_device_remove(), when napi_disable is called for those subchannels, napi_disable gets stuck on infinite msleep.

This fix addresses this problem by ensuring that napi_disable() is not getting called for non-enabled NAPI struct. But netif_napi_del() is still necessary for these non-enabled NAPI struct for cleanup purpose.

Call trace: [ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002 [ 654.568030] Call Trace: [ 654.571221] <TASK> [ 654.573790] __schedule+0x2d6/0x960 [ 654.577733] schedule+0x69/0xf0 [ 654.581214] schedule_timeout+0x87/0x140 [ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napi_disable+0x2b/0x80 [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] [ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] [ 654.611101] ? do_wait_intr+0xb0/0xb0 [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] [ 654.621675] vmbus_remove+0x27/0x40 hv_vmbus

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

afs: Increase buffer size in afs_update_volume_status()

The max length of volume->vid value is 20 characters. So increase idbuf[] size up to 24 to avoid overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()

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

ARM: ep93xx: Add terminator to gpiod_lookup_table

Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops.(CVE-2024-26751)

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

fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio

If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the following kernel warning appears:

WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8 Call trace: kiocb_set_cancel_fn+0x9c/0xa8 ffs_epfile_read_iter+0x144/0x1d0 io_read+0x19c/0x498 io_issue_sqe+0x118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb4/0xf4 do_el0_svc+0x2c/0xb0 el0_svc+0x2c/0xa4 el0t_64_sync_handler+0x68/0xb4 el0t_64_sync+0x1a4/0x1a8

Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is submitted by libaio.(CVE-2024-26764)

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

ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()

Places the logic for checking if the group's block bitmap is corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted block bitmap.(CVE-2024-26772)

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

ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()

Determine if the group block bitmap is corrupted before using ac_b_ex in ext4_mb_try_best_found() to avoid allocating blocks from a group with a corrupted block bitmap in the following concurrency and making the situation worse.

ext4_mb_regular_allocator ext4_lock_group(sb, group) ext4_mb_good_group // check if the group bbitmap is corrupted ext4_mb_complex_scan_group // Scan group gets ac_b_ex but doesn't use it ext4_unlock_group(sb, group) ext4_mark_group_bitmap_corrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4_mb_try_best_found ext4_lock_group(ac->ac_sb, group) ext4_mb_use_best_found mb_mark_used // Allocating blocks in block bitmap corrupted group(CVE-2024-26773)

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

fbdev: sis: Error out if pixclock equals zero

The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error.

In sisfb_check_var(), var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by checking it at the beginning.

This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.(CVE-2024-26777)

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

fbdev: savage: Error out if pixclock equals zero

The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error.

Although pixclock is checked in savagefb_decode_var(), but it is not checked properly in savagefb_probe(). Fix this by checking whether pixclock is zero in the function savagefb_check_var() before info->var.pixclock is used as the divisor.

This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.(CVE-2024-26778)

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

dmaengine: fsl-qdma: init irq after reg initialization

Initialize the qDMA irqs after the registers are configured so that interrupts that may have been pending from a primary kernel don't get processed by the irq handler before it is ready to and cause panic with the following trace:

Call trace: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x178 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/0xe8 fsl_qdma_probe+0x4d4/0xca8 platform_drv_probe+0x50/0xa0 really_probe+0xe0/0x3f8 driver_probe_device+0x64/0x130 device_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable+0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18(CVE-2024-26788)

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

vfio/pci: Lock external INTx masking ops

Mask operations through config space changes to DisINTx may race INTx configuration changes via ioctl. Create wrappers that add locking for paths outside of the core interrupt code.

In particular, irq_type is updated holding igate, therefore testing is_intx() requires holding igate. For example clearing DisINTx from config space can otherwise race changes of the interrupt configuration.

This aligns interfaces which may trigger the INTx eventfd into two camps, one side serialized by igate and the other only enabled while INTx is configured. A subsequent patch introduces synchronization for the latter flows.(CVE-2024-26810)

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

bpf: Fix stackmap overflow check on 32-bit arches

The stackmap code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code.

The commit in the fixes tag actually attempted to fix this, but the fix did not account for the UB, so the fix only works on CPUs where an overflow does result in a neat truncation to zero, which is not guaranteed. Checking the value before rounding does not have this problem.(CVE-2024-26883)

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

bpf: Fix hashtab overflow check on 32-bit arches

The hashtab code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check to before the roundup.(CVE-2024-26884)

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

bpf: Fix DEVMAP_HASH overflow check on 32-bit arches

The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end.

Syzbot managed to turn this into a crash on arm32 by creating a DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation.(CVE-2024-26885)

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

vfio/pci: Disable auto-enable of exclusive INTx IRQ

Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio.

Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx is never auto-enabled, then unmask as required.(CVE-2024-27437)

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": [
          "perf-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm",
          "kernel-devel-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm",
          "kernel-tools-devel-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm",
          "kernel-debugsource-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm",
          "perf-debuginfo-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm",
          "kernel-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm",
          "kernel-debuginfo-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm",
          "python3-perf-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm",
          "kernel-headers-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm",
          "kernel-source-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm",
          "kernel-tools-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-153.53.0.131.oe2203sp2.src.rpm"
        ],
        "x86_64": [
          "kernel-headers-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm",
          "kernel-tools-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm",
          "kernel-source-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm",
          "python3-perf-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm",
          "perf-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm",
          "perf-debuginfo-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm",
          "kernel-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm",
          "kernel-tools-devel-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm",
          "kernel-debuginfo-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm",
          "kernel-debugsource-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm",
          "kernel-devel-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP2",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-153.53.0.131.oe2203sp2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\ncreate_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi-\u0026gt;leb_size.(CVE-2024-25739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/bridge: sii902x: Fix probing race issue\r\n\r\nA null pointer dereference crash has been observed rarely on TI\nplatforms using sii9022 bridge:\r\n\r\n[   53.271356]  sii902x_get_edid+0x34/0x70 [sii902x]\n[   53.276066]  sii902x_bridge_get_edid+0x14/0x20 [sii902x]\n[   53.281381]  drm_bridge_get_edid+0x20/0x34 [drm]\n[   53.286305]  drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper]\n[   53.292955]  drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper]\n[   53.300510]  drm_client_modeset_probe+0x1f0/0xbd4 [drm]\n[   53.305958]  __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper]\n[   53.313611]  drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper]\n[   53.320039]  drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper]\n[   53.326401]  drm_client_register+0x5c/0xa0 [drm]\n[   53.331216]  drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper]\n[   53.336881]  tidss_probe+0x128/0x264 [tidss]\n[   53.341174]  platform_probe+0x68/0xc4\n[   53.344841]  really_probe+0x188/0x3c4\n[   53.348501]  __driver_probe_device+0x7c/0x16c\n[   53.352854]  driver_probe_device+0x3c/0x10c\n[   53.357033]  __device_attach_driver+0xbc/0x158\n[   53.361472]  bus_for_each_drv+0x88/0xe8\n[   53.365303]  __device_attach+0xa0/0x1b4\n[   53.369135]  device_initial_probe+0x14/0x20\n[   53.373314]  bus_probe_device+0xb0/0xb4\n[   53.377145]  deferred_probe_work_func+0xcc/0x124\n[   53.381757]  process_one_work+0x1f0/0x518\n[   53.385770]  worker_thread+0x1e8/0x3dc\n[   53.389519]  kthread+0x11c/0x120\n[   53.392750]  ret_from_fork+0x10/0x20\r\n\r\nThe issue here is as follows:\r\n\r\n- tidss probes, but is deferred as sii902x is still missing.\n- sii902x starts probing and enters sii902x_init().\n- sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from\n  DRM\u0026apos;s perspective.\n- sii902x calls sii902x_audio_codec_init() and\n  platform_device_register_data()\n- The registration of the audio platform device causes probing of the\n  deferred devices.\n- tidss probes, which eventually causes sii902x_bridge_get_edid() to be\n  called.\n- sii902x_bridge_get_edid() tries to use the i2c to read the edid.\n  However, the sii902x driver has not set up the i2c part yet, leading\n  to the crash.\r\n\r\nFix this by moving the drm_bridge_add() to the end of the\nsii902x_init(), which is also at the very end of sii902x_probe().(CVE-2024-26607)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: make sure init the accept_queue\u0026apos;s spinlocks once\r\n\r\nWhen I run syz\u0026apos;s reproduction C program locally, it causes the following\nissue:\npvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!\nWARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)\nHardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011\nRIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)\nCode: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7\n30 20 ce 8f e8 ad 56 42 ff \u0026lt;0f\u0026gt; 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90\nRSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908\nRDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900\nRBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff\nR10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000\nR13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000\nFS:  00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0\nCall Trace:\n\u0026lt;IRQ\u0026gt;\n  _raw_spin_unlock (kernel/locking/spinlock.c:186)\n  inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)\n  inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)\n  tcp_check_req (net/ipv4/tcp_minisocks.c:868)\n  tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)\n  ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)\n  ip_local_deliver_finish (net/ipv4/ip_input.c:234)\n  __netif_receive_skb_one_core (net/core/dev.c:5529)\n  process_backlog (./include/linux/rcupdate.h:779)\n  __napi_poll (net/core/dev.c:6533)\n  net_rx_action (net/core/dev.c:6604)\n  __do_softirq (./arch/x86/include/asm/jump_label.h:27)\n  do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)\n\u0026lt;/IRQ\u0026gt;\n\u0026lt;TASK\u0026gt;\n  __local_bh_enable_ip (kernel/softirq.c:381)\n  __dev_queue_xmit (net/core/dev.c:4374)\n  ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)\n  __ip_queue_xmit (net/ipv4/ip_output.c:535)\n  __tcp_transmit_skb (net/ipv4/tcp_output.c:1462)\n  tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)\n  tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)\n  tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)\n  __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)\n  release_sock (net/core/sock.c:3536)\n  inet_wait_for_connect (net/ipv4/af_inet.c:609)\n  __inet_stream_connect (net/ipv4/af_inet.c:702)\n  inet_stream_connect (net/ipv4/af_inet.c:748)\n  __sys_connect (./include/linux/file.h:45 net/socket.c:2064)\n  __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)\n  do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)\n  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)\n  RIP: 0033:0x7fa10ff05a3d\n  Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89\n  c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48\n  RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a\n  RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d\n  RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003\n  RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640\n  R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20\n\u0026lt;/TASK\u0026gt;\r\n\r\nThe issue triggering process is analyzed as follows:\nThread A                                       Thread B\ntcp_v4_rcv\t//receive ack TCP packet       inet_shutdown\n  tcp_check_req                                  tcp_disconnect //disconnect sock\n  ...                                              tcp_set_state(sk, TCP_CLOSE)\n    inet_csk_complete_hashdance                ...\n      inet_csk_reqsk_queue_add         \n---truncated---(CVE-2024-26614)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t abort filesystem when attempting to snapshot deleted subvolume\r\n\r\nIf the source file descriptor to the snapshot ioctl refers to a deleted\nsubvolume, we get the following abort:\r\n\r\n  BTRFS: Transaction aborted (error -2)\n  WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]\n  Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c\n  CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014\n  RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]\n  RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282\n  RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027\n  RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840\n  RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998\n  R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe\n  R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80\n  FS:  00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? create_pending_snapshot+0x1040/0x1190 [btrfs]\n   ? __warn+0x81/0x130\n   ? create_pending_snapshot+0x1040/0x1190 [btrfs]\n   ? report_bug+0x171/0x1a0\n   ? handle_bug+0x3a/0x70\n   ? exc_invalid_op+0x17/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? create_pending_snapshot+0x1040/0x1190 [btrfs]\n   ? create_pending_snapshot+0x1040/0x1190 [btrfs]\n   create_pending_snapshots+0x92/0xc0 [btrfs]\n   btrfs_commit_transaction+0x66b/0xf40 [btrfs]\n   btrfs_mksubvol+0x301/0x4d0 [btrfs]\n   btrfs_mksnapshot+0x80/0xb0 [btrfs]\n   __btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs]\n   btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs]\n   btrfs_ioctl+0x8a6/0x2650 [btrfs]\n   ? kmem_cache_free+0x22/0x340\n   ? do_sys_openat2+0x97/0xe0\n   __x64_sys_ioctl+0x97/0xd0\n   do_syscall_64+0x46/0xf0\n   entry_SYSCALL_64_after_hwframe+0x6e/0x76\n  RIP: 0033:0x7fe20abe83af\n  RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n  RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af\n  RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003\n  RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0\n  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n  R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58\n   \u0026lt;/TASK\u0026gt;\n  ---[ end trace 0000000000000000 ]---\n  BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry\n  BTRFS info (device vdc: state EA): forced readonly\n  BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction.\n  BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry\r\n\r\nThis happens because create_pending_snapshot() initializes the new root\nitem as a copy of the source root item. This includes the refs field,\nwhich is 0 for a deleted subvolume. The call to btrfs_insert_root()\ntherefore inserts a root with refs == 0. btrfs_get_new_fs_root() then\nfinds the root and returns -ENOENT if refs == 0, which causes\ncreate_pending_snapshot() to abort.\r\n\r\nFix it by checking the source root\u0026apos;s refs before attempting the\nsnapshot, but after locking subvol_sem to avoid racing with deletion.(CVE-2024-26644)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhv_netvsc: Fix race condition between netvsc_probe and netvsc_remove\r\n\r\nIn commit ac5047671758 (\u0026quot;hv_netvsc: Disable NAPI before closing the\nVMBus channel\u0026quot;), napi_disable was getting called for all channels,\nincluding all subchannels without confirming if they are enabled or not.\r\n\r\nThis caused hv_netvsc getting hung at napi_disable, when netvsc_probe()\nhas finished running but nvdev-\u0026gt;subchan_work has not started yet.\nnetvsc_subchan_work() -\u0026gt; rndis_set_subchannel() has not created the\nsub-channels and because of that netvsc_sc_open() is not running.\nnetvsc_remove() calls cancel_work_sync(\u0026amp;nvdev-\u0026gt;subchan_work), for which\nnetvsc_subchan_work did not run.\r\n\r\nnetif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI\ncannot be scheduled. Then netvsc_sc_open() -\u0026gt; napi_enable will clear the\nNAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the\nopposite.\r\n\r\nNow during netvsc_device_remove(), when napi_disable is called for those\nsubchannels, napi_disable gets stuck on infinite msleep.\r\n\r\nThis fix addresses this problem by ensuring that napi_disable() is not\ngetting called for non-enabled NAPI struct.\nBut netif_napi_del() is still necessary for these non-enabled NAPI struct\nfor cleanup purpose.\r\n\r\nCall trace:\n[  654.559417] task:modprobe        state:D stack:    0 pid: 2321 ppid:  1091 flags:0x00004002\n[  654.568030] Call Trace:\n[  654.571221]  \u0026lt;TASK\u0026gt;\n[  654.573790]  __schedule+0x2d6/0x960\n[  654.577733]  schedule+0x69/0xf0\n[  654.581214]  schedule_timeout+0x87/0x140\n[  654.585463]  ? __bpf_trace_tick_stop+0x20/0x20\n[  654.590291]  msleep+0x2d/0x40\n[  654.593625]  napi_disable+0x2b/0x80\n[  654.597437]  netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]\n[  654.603935]  rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]\n[  654.611101]  ? do_wait_intr+0xb0/0xb0\n[  654.615753]  netvsc_remove+0x7c/0x120 [hv_netvsc]\n[  654.621675]  vmbus_remove+0x27/0x40 [hv_vmbus](CVE-2024-26698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nafs: Increase buffer size in afs_update_volume_status()\r\n\r\nThe max length of volume-\u0026gt;vid value is 20 characters.\nSo increase idbuf[] size up to 24 to avoid overflow.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\r\n\r\n[DH: Actually, it\u0026apos;s 20 + NUL, so increase it to 24 and use snprintf()](CVE-2024-26736)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nARM: ep93xx: Add terminator to gpiod_lookup_table\r\n\r\nWithout the terminator, if a con_id is passed to gpio_find() that\ndoes not exist in the lookup table the function will not stop looping\ncorrectly, and eventually cause an oops.(CVE-2024-26751)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio\r\n\r\nIf kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the\nfollowing kernel warning appears:\r\n\r\nWARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8\nCall trace:\n kiocb_set_cancel_fn+0x9c/0xa8\n ffs_epfile_read_iter+0x144/0x1d0\n io_read+0x19c/0x498\n io_issue_sqe+0x118/0x27c\n io_submit_sqes+0x25c/0x5fc\n __arm64_sys_io_uring_enter+0x104/0xab0\n invoke_syscall+0x58/0x11c\n el0_svc_common+0xb4/0xf4\n do_el0_svc+0x2c/0xb0\n el0_svc+0x2c/0xa4\n el0t_64_sync_handler+0x68/0xb4\n el0t_64_sync+0x1a4/0x1a8\r\n\r\nFix this by setting the IOCB_AIO_RW flag for read and write I/O that is\nsubmitted by libaio.(CVE-2024-26764)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()\r\n\r\nPlaces the logic for checking if the group\u0026apos;s block bitmap is corrupt under\nthe protection of the group lock to avoid allocating blocks from the group\nwith a corrupted block bitmap.(CVE-2024-26772)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()\r\n\r\nDetermine if the group block bitmap is corrupted before using ac_b_ex in\next4_mb_try_best_found() to avoid allocating blocks from a group with a\ncorrupted block bitmap in the following concurrency and making the\nsituation worse.\r\n\r\next4_mb_regular_allocator\n  ext4_lock_group(sb, group)\n  ext4_mb_good_group\n   // check if the group bbitmap is corrupted\n  ext4_mb_complex_scan_group\n   // Scan group gets ac_b_ex but doesn\u0026apos;t use it\n  ext4_unlock_group(sb, group)\n                           ext4_mark_group_bitmap_corrupted(group)\n                           // The block bitmap was corrupted during\n                           // the group unlock gap.\n  ext4_mb_try_best_found\n    ext4_lock_group(ac-\u0026gt;ac_sb, group)\n    ext4_mb_use_best_found\n      mb_mark_used\n      // Allocating blocks in block bitmap corrupted group(CVE-2024-26773)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbdev: sis: Error out if pixclock equals zero\r\n\r\nThe userspace program could pass any values to the driver through\nioctl() interface. If the driver doesn\u0026apos;t check the value of pixclock,\nit may cause divide-by-zero error.\r\n\r\nIn sisfb_check_var(), var-\u0026gt;pixclock is used as a divisor to caculate\ndrate before it is checked against zero. Fix this by checking it\nat the beginning.\r\n\r\nThis is similar to CVE-2022-3061 in i740fb which was fixed by\ncommit 15cf0b8.(CVE-2024-26777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbdev: savage: Error out if pixclock equals zero\r\n\r\nThe userspace program could pass any values to the driver through\nioctl() interface. If the driver doesn\u0026apos;t check the value of pixclock,\nit may cause divide-by-zero error.\r\n\r\nAlthough pixclock is checked in savagefb_decode_var(), but it is not\nchecked properly in savagefb_probe(). Fix this by checking whether\npixclock is zero in the function savagefb_check_var() before\ninfo-\u0026gt;var.pixclock is used as the divisor.\r\n\r\nThis is similar to CVE-2022-3061 in i740fb which was fixed by\ncommit 15cf0b8.(CVE-2024-26778)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: fsl-qdma: init irq after reg initialization\r\n\r\nInitialize the qDMA irqs after the registers are configured so that\ninterrupts that may have been pending from a primary kernel don\u0026apos;t get\nprocessed by the irq handler before it is ready to and cause panic with\nthe following trace:\r\n\r\n  Call trace:\n   fsl_qdma_queue_handler+0xf8/0x3e8\n   __handle_irq_event_percpu+0x78/0x2b0\n   handle_irq_event_percpu+0x1c/0x68\n   handle_irq_event+0x44/0x78\n   handle_fasteoi_irq+0xc8/0x178\n   generic_handle_irq+0x24/0x38\n   __handle_domain_irq+0x90/0x100\n   gic_handle_irq+0x5c/0xb8\n   el1_irq+0xb8/0x180\n   _raw_spin_unlock_irqrestore+0x14/0x40\n   __setup_irq+0x4bc/0x798\n   request_threaded_irq+0xd8/0x190\n   devm_request_threaded_irq+0x74/0xe8\n   fsl_qdma_probe+0x4d4/0xca8\n   platform_drv_probe+0x50/0xa0\n   really_probe+0xe0/0x3f8\n   driver_probe_device+0x64/0x130\n   device_driver_attach+0x6c/0x78\n   __driver_attach+0xbc/0x158\n   bus_for_each_dev+0x5c/0x98\n   driver_attach+0x20/0x28\n   bus_add_driver+0x158/0x220\n   driver_register+0x60/0x110\n   __platform_driver_register+0x44/0x50\n   fsl_qdma_driver_init+0x18/0x20\n   do_one_initcall+0x48/0x258\n   kernel_init_freeable+0x1a4/0x23c\n   kernel_init+0x10/0xf8\n   ret_from_fork+0x10/0x18(CVE-2024-26788)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/pci: Lock external INTx masking ops\r\n\r\nMask operations through config space changes to DisINTx may race INTx\nconfiguration changes via ioctl.  Create wrappers that add locking for\npaths outside of the core interrupt code.\r\n\r\nIn particular, irq_type is updated holding igate, therefore testing\nis_intx() requires holding igate.  For example clearing DisINTx from\nconfig space can otherwise race changes of the interrupt configuration.\r\n\r\nThis aligns interfaces which may trigger the INTx eventfd into two\ncamps, one side serialized by igate and the other only enabled while\nINTx is configured.  A subsequent patch introduces synchronization for\nthe latter flows.(CVE-2024-26810)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Fix stackmap overflow check on 32-bit arches\r\n\r\nThe stackmap code relies on roundup_pow_of_two() to compute the number\nof hash buckets, and contains an overflow check by checking if the\nresulting value is 0. However, on 32-bit arches, the roundup code itself\ncan overflow by doing a 32-bit left-shift of an unsigned long value,\nwhich is undefined behaviour, so it is not guaranteed to truncate\nneatly. This was triggered by syzbot on the DEVMAP_HASH type, which\ncontains the same check, copied from the hashtab code.\r\n\r\nThe commit in the fixes tag actually attempted to fix this, but the fix\ndid not account for the UB, so the fix only works on CPUs where an\noverflow does result in a neat truncation to zero, which is not\nguaranteed. Checking the value before rounding does not have this\nproblem.(CVE-2024-26883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Fix hashtab overflow check on 32-bit arches\r\n\r\nThe hashtab code relies on roundup_pow_of_two() to compute the number of\nhash buckets, and contains an overflow check by checking if the\nresulting value is 0. However, on 32-bit arches, the roundup code itself\ncan overflow by doing a 32-bit left-shift of an unsigned long value,\nwhich is undefined behaviour, so it is not guaranteed to truncate\nneatly. This was triggered by syzbot on the DEVMAP_HASH type, which\ncontains the same check, copied from the hashtab code. So apply the same\nfix to hashtab, by moving the overflow check to before the roundup.(CVE-2024-26884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Fix DEVMAP_HASH overflow check on 32-bit arches\r\n\r\nThe devmap code allocates a number hash buckets equal to the next power\nof two of the max_entries value provided when creating the map. When\nrounding up to the next power of two, the 32-bit variable storing the\nnumber of buckets can overflow, and the code checks for overflow by\nchecking if the truncated 32-bit value is equal to 0. However, on 32-bit\narches the rounding up itself can overflow mid-way through, because it\nends up doing a left-shift of 32 bits on an unsigned long value. If the\nsize of an unsigned long is four bytes, this is undefined behaviour, so\nthere is no guarantee that we\u0026apos;ll end up with a nice and tidy 0-value at\nthe end.\r\n\r\nSyzbot managed to turn this into a crash on arm32 by creating a\nDEVMAP_HASH with max_entries \u0026gt; 0x80000000 and then trying to update it.\nFix this by moving the overflow check to before the rounding up\noperation.(CVE-2024-26885)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/pci: Disable auto-enable of exclusive INTx IRQ\r\n\r\nCurrently for devices requiring masking at the irqchip for INTx, ie.\ndevices without DisINTx support, the IRQ is enabled in request_irq()\nand subsequently disabled as necessary to align with the masked status\nflag.  This presents a window where the interrupt could fire between\nthese events, resulting in the IRQ incrementing the disable depth twice.\nThis would be unrecoverable for a user since the masked flag prevents\nnested enables through vfio.\r\n\r\nInstead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx\nis never auto-enabled, then unmask as required.(CVE-2024-27437)",
  "id": "OESA-2024-1520",
  "modified": "2026-08-06T11:06:57Z",
  "published": "2024-05-10T11:06:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1520"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26607"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26614"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26644"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26698"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26736"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26751"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26764"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26772"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26773"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26777"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26778"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26788"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26810"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26883"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26884"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26885"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27437"
    }
  ],
  "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-25739",
    "CVE-2024-26607",
    "CVE-2024-26614",
    "CVE-2024-26644",
    "CVE-2024-26698",
    "CVE-2024-26736",
    "CVE-2024-26751",
    "CVE-2024-26764",
    "CVE-2024-26772",
    "CVE-2024-26773",
    "CVE-2024-26777",
    "CVE-2024-26778",
    "CVE-2024-26788",
    "CVE-2024-26810",
    "CVE-2024-26883",
    "CVE-2024-26884",
    "CVE-2024-26885",
    "CVE-2024-27437"
  ]
}



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.