OESA-2024-1526 (CVE-2021-47121)
Vulnerability from osv_openeuler – Published: 2024-05-10 11:06 – Updated: 2026-08-06 11:06 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: caif: fix memory leak in cfusbl_device_notify
In case of caif_enroll_dev() fail, allocated link_support won't be assigned to the corresponding structure. So simply free allocated pointer in case of error.(CVE-2021-47121)
In the Linux kernel, the following vulnerability has been resolved:
net: fujitsu: fix potential null-ptr-deref
In fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer deref. To fix this, check the return value of ioremap and return -1 to the caller in case of failure.(CVE-2021-47149)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix link down processing to address NULL pointer dereference
If an FC link down transition while PLOGIs are outstanding to fabric well known addresses, outstanding ABTS requests may result in a NULL pointer dereference. Driver unload requests may hang with repeated "2878" log messages.
The Link down processing results in ABTS requests for outstanding ELS requests. The Abort WQEs are sent for the ELSs before the driver had set the link state to down. Thus the driver is sending the Abort with the expectation that an ABTS will be sent on the wire. The Abort request is stalled waiting for the link to come up. In some conditions the driver may auto-complete the ELSs thus if the link does come up, the Abort completions may reference an invalid structure.
Fix by ensuring that Abort set the flag to avoid link traffic if issued due to conditions where the link failed.(CVE-2021-47183)
In the Linux kernel, the following vulnerability has been resolved:
cfg80211: call cfg80211_stop_ap when switch from P2P_GO type
If the userspace tools switch from NL80211_IFTYPE_P2P_GO to NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it does not call the cleanup cfg80211_stop_ap(), this leads to the initialization of in-use data. For example, this path re-init the sdata->assigned_chanctx_list while it is still an element of assigned_vifs list, and makes that linked list corrupt.(CVE-2021-47194)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tipd: Remove WARN_ON in tps6598x_block_read
Calling tps6598x_block_read with a higher than allowed len can be handled by just returning an error. There's no need to crash systems with panic-on-warn enabled.(CVE-2021-47210)
In the Linux kernel, the following vulnerability has been resolved:
pstore/ram: Fix crash when setting number of cpus to an odd number
When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va.
So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug.(CVE-2023-52619)
A race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
(CVE-2024-24860)
In the Linux kernel, the following vulnerability has been resolved:
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
Reading frag_off can only be done if we pulled enough bytes to skb->head. Currently we might access garbage.
[1] BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [inline] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [inline] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2584 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098 __pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655 pskb_may_pull_reason include/linux/skbuff.h:2673 [inline] pskb_may_pull include/linux/skbuff.h:2681 [inline] ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [inline] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [inline] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2584 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendms ---truncated---(CVE-2024-26633)
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:
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:
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 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:
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)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"python2-perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"bpftool-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2405.1.0.0275.oe2003sp4.src.rpm"
],
"x86_64": [
"kernel-tools-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"bpftool-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2405.1.0.0275.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: caif: fix memory leak in cfusbl_device_notify\r\n\r\nIn case of caif_enroll_dev() fail, allocated\nlink_support won\u0026apos;t be assigned to the corresponding\nstructure. So simply free allocated pointer in case\nof error.(CVE-2021-47121)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fujitsu: fix potential null-ptr-deref\r\n\r\nIn fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer\nderef. To fix this, check the return value of ioremap and return -1\nto the caller in case of failure.(CVE-2021-47149)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix link down processing to address NULL pointer dereference\r\n\r\nIf an FC link down transition while PLOGIs are outstanding to fabric well\nknown addresses, outstanding ABTS requests may result in a NULL pointer\ndereference. Driver unload requests may hang with repeated \u0026quot;2878\u0026quot; log\nmessages.\r\n\r\nThe Link down processing results in ABTS requests for outstanding ELS\nrequests. The Abort WQEs are sent for the ELSs before the driver had set\nthe link state to down. Thus the driver is sending the Abort with the\nexpectation that an ABTS will be sent on the wire. The Abort request is\nstalled waiting for the link to come up. In some conditions the driver may\nauto-complete the ELSs thus if the link does come up, the Abort completions\nmay reference an invalid structure.\r\n\r\nFix by ensuring that Abort set the flag to avoid link traffic if issued due\nto conditions where the link failed.(CVE-2021-47183)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncfg80211: call cfg80211_stop_ap when switch from P2P_GO type\r\n\r\nIf the userspace tools switch from NL80211_IFTYPE_P2P_GO to\nNL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it\ndoes not call the cleanup cfg80211_stop_ap(), this leads to the\ninitialization of in-use data. For example, this path re-init the\nsdata-\u0026gt;assigned_chanctx_list while it is still an element of\nassigned_vifs list, and makes that linked list corrupt.(CVE-2021-47194)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: tipd: Remove WARN_ON in tps6598x_block_read\r\n\r\nCalling tps6598x_block_read with a higher than allowed len can be\nhandled by just returning an error. There\u0026apos;s no need to crash systems\nwith panic-on-warn enabled.(CVE-2021-47210)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore/ram: Fix crash when setting number of cpus to an odd number\r\n\r\nWhen the number of cpu cores is adjusted to 7 or other odd numbers,\nthe zone size will become an odd number.\nThe address of the zone will become:\n addr of zone0 = BASE\n addr of zone1 = BASE + zone_size\n addr of zone2 = BASE + zone_size*2\n ...\nThe address of zone1/3/5/7 will be mapped to non-alignment va.\nEventually crashes will occur when accessing these va.\r\n\r\nSo, use ALIGN_DOWN() to make sure the zone size is even\nto avoid this bug.(CVE-2023-52619)\r\n\r\nA race condition was found in the Linux kernel\u0026apos;s bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.\r\n\r\n\r\n\r\n\n(CVE-2024-24860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()\r\n\r\nsyzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.\r\n\r\nReading frag_off can only be done if we pulled enough bytes\nto skb-\u0026gt;head. Currently we might access garbage.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0\nip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0\nipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]\nip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432\n__netdev_start_xmit include/linux/netdevice.h:4940 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4954 [inline]\nxmit_one net/core/dev.c:3548 [inline]\ndev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\ndev_queue_xmit include/linux/netdevice.h:3134 [inline]\nneigh_connected_output+0x569/0x660 net/core/neighbour.c:1592\nneigh_output include/net/neighbour.h:542 [inline]\nip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137\nip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222\nNF_HOOK_COND include/linux/netfilter.h:303 [inline]\nip6_output+0x323/0x610 net/ipv6/ip6_output.c:243\ndst_output include/net/dst.h:451 [inline]\nip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155\nip6_send_skb net/ipv6/ip6_output.c:1952 [inline]\nip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972\nrawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582\nrawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920\ninet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg net/socket.c:745 [inline]\n____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n__sys_sendmsg net/socket.c:2667 [inline]\n__do_sys_sendmsg net/socket.c:2676 [inline]\n__se_sys_sendmsg net/socket.c:2674 [inline]\n__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\nslab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\nslab_alloc_node mm/slub.c:3478 [inline]\n__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517\n__do_kmalloc_node mm/slab_common.c:1006 [inline]\n__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027\nkmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582\npskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098\n__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655\npskb_may_pull_reason include/linux/skbuff.h:2673 [inline]\npskb_may_pull include/linux/skbuff.h:2681 [inline]\nip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408\nipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]\nip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432\n__netdev_start_xmit include/linux/netdevice.h:4940 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4954 [inline]\nxmit_one net/core/dev.c:3548 [inline]\ndev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\ndev_queue_xmit include/linux/netdevice.h:3134 [inline]\nneigh_connected_output+0x569/0x660 net/core/neighbour.c:1592\nneigh_output include/net/neighbour.h:542 [inline]\nip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137\nip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222\nNF_HOOK_COND include/linux/netfilter.h:303 [inline]\nip6_output+0x323/0x610 net/ipv6/ip6_output.c:243\ndst_output include/net/dst.h:451 [inline]\nip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155\nip6_send_skb net/ipv6/ip6_output.c:1952 [inline]\nip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972\nrawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582\nrawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920\ninet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg net/socket.c:745 [inline]\n____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n__sys_sendmsg net/socket.c:2667 [inline]\n__do_sys_sendms\n---truncated---(CVE-2024-26633)\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\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\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 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\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-1526",
"modified": "2026-08-06T11:06:58Z",
"published": "2024-05-10T11:06:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1526"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47121"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47183"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47210"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52619"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24860"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26633"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26644"
},
{
"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-26810"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26884"
},
{
"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-2021-47121",
"CVE-2021-47149",
"CVE-2021-47183",
"CVE-2021-47194",
"CVE-2021-47210",
"CVE-2023-52619",
"CVE-2024-24860",
"CVE-2024-26633",
"CVE-2024-26644",
"CVE-2024-26751",
"CVE-2024-26764",
"CVE-2024-26772",
"CVE-2024-26773",
"CVE-2024-26777",
"CVE-2024-26778",
"CVE-2024-26810",
"CVE-2024-26884",
"CVE-2024-27437"
]
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.