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

OESA-2025-1513 (CVE-2022-49111)

Vulnerability from osv_openeuler – Published: 2025-05-16 11:08 – Updated: 2026-08-06 11:08 – Source website
VLAI
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:

Bluetooth: Fix use after free in hci_send_acl

This fixes the following trace caused by receiving HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without first checking if conn->type is in fact AMP_LINK and in case it is do properly cleanup upper layers with hci_disconn_cfm:

================================================================== BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50 Read of size 8 at addr ffff88800e404818 by task bluetoothd/142

CPU: 0 PID: 142 Comm: bluetoothd Not tainted
5.17.0-rc5-00006-gda4022eeac1a #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x45/0x59
 print_address_description.constprop.0+0x1f/0x150
 kasan_report.cold+0x7f/0x11b
 hci_send_acl+0xaba/0xc50
 l2cap_do_send+0x23f/0x3d0
 l2cap_chan_send+0xc06/0x2cc0
 l2cap_sock_sendmsg+0x201/0x2b0
 sock_sendmsg+0xdc/0x110
 sock_write_iter+0x20f/0x370
 do_iter_readv_writev+0x343/0x690
 do_iter_write+0x132/0x640
 vfs_writev+0x198/0x570
 do_writev+0x202/0x280
 do_syscall_64+0x38/0x90
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3
0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05
<48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015
RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77
R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580
RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001
</TASK>
R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0

Allocated by task 45:
    kasan_save_stack+0x1e/0x40
    __kasan_kmalloc+0x81/0xa0
    hci_chan_create+0x9a/0x2f0
    l2cap_conn_add.part.0+0x1a/0xdc0
    l2cap_connect_cfm+0x236/0x1000
    le_conn_complete_evt+0x15a7/0x1db0
    hci_le_conn_complete_evt+0x226/0x2c0
    hci_le_meta_evt+0x247/0x450
    hci_event_packet+0x61b/0xe90
    hci_rx_work+0x4d5/0xc50
    process_one_work+0x8fb/0x15a0
    worker_thread+0x576/0x1240
    kthread+0x29d/0x340
    ret_from_fork+0x1f/0x30

Freed by task 45:
    kasan_save_stack+0x1e/0x40
    kasan_set_track+0x21/0x30
    kasan_set_free_info+0x20/0x30
    __kasan_slab_free+0xfb/0x130
    kfree+0xac/0x350
    hci_conn_cleanup+0x101/0x6a0
    hci_conn_del+0x27e/0x6c0
    hci_disconn_phylink_complete_evt+0xe0/0x120
    hci_event_packet+0x812/0xe90
    hci_rx_work+0x4d5/0xc50
    process_one_work+0x8fb/0x15a0
    worker_thread+0x576/0x1240
    kthread+0x29d/0x340
    ret_from_fork+0x1f/0x30

The buggy address belongs to the object at ffff88800c0f0500
The buggy address is located 24 bytes inside of
which belongs to the cache kmalloc-128 of size 128
The buggy address belongs to the page:
128-byte region [ffff88800c0f0500, ffff88800c0f0580)
flags: 0x100000000000200(slab|node=0|zone=1)
page:00000000fe45cd86 refcount:1 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0xc0f0
raw: 0000000000000000 0000000080100010 00000001ffffffff
0000000000000000
raw: 0100000000000200 ffffea00003a2c80 dead000000000004
ffff8880078418c0
page dumped because: kasan: bad access detected
ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
Memory state around the buggy address:
>ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

---truncated---(CVE-2022-49111)

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

NFC: NULL out the dev->rfkill to prevent UAF

Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device") assumes the device_is_registered() in function nfc_dev_up() will help to check when the rfkill is unregistered. However, this check only take effect when device_del(&dev->dev) is done in nfc_unregister_device(). Hence, the rfkill object is still possible be dereferenced.

The crash trace in latest kernel (5.18-rc2):

[ 68.760105] ================================================================== [ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750 [ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313 [ 68.760756] [ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4 [ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 68.760756] Call Trace: [ 68.760756] <TASK> [ 68.760756] dump_stack_lvl+0x57/0x7d [ 68.760756] print_report.cold+0x5e/0x5db [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] kasan_report+0xbe/0x1c0 [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] __lock_acquire+0x3ec1/0x6750 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? register_lock_class+0x18d0/0x18d0 [ 68.760756] lock_acquire+0x1ac/0x4f0 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0 [ 68.760756] ? nla_get_range_signed+0x540/0x540 [ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50 [ 68.760756] _raw_spin_lock_irqsave+0x39/0x50 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] rfkill_blocked+0xe/0x60 [ 68.760756] nfc_dev_up+0x84/0x260 [ 68.760756] nfc_genl_dev_up+0x90/0xe0 [ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0 [ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230 [ 68.760756] ? security_capable+0x51/0x90 [ 68.760756] genl_rcv_msg+0x280/0x500 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? lock_acquire+0x1ac/0x4f0 [ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] netlink_rcv_skb+0x11b/0x340 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? netlink_ack+0x9c0/0x9c0 [ 68.760756] ? netlink_deliver_tap+0x136/0xb00 [ 68.760756] genl_rcv+0x1f/0x30 [ 68.760756] netlink_unicast+0x430/0x710 [ 68.760756] ? memset+0x20/0x40 [ 68.760756] ? netlink_attachskb+0x740/0x740 [ 68.760756] ? __build_skb_around+0x1f4/0x2a0 [ 68.760756] netlink_sendmsg+0x75d/0xc00 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] sock_sendmsg+0xdf/0x110 [ 68.760756] __sys_sendto+0x19e/0x270 [ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0 [ 68.760756] ? fd_install+0x178/0x4c0 [ 68.760756] ? fd_install+0x195/0x4c0 [ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0 [ 68.760756] __x64_sys_sendto+0xd8/0x1b0 [ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130 [ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50 [ 68.760756] do_syscall_64+0x3b/0x90 [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 68.760756] RIP: 0033:0x7f67fb50e6b3 ... [ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3 [ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003 [ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c [ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e [ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003

[ 68.760756] </TASK> [ 68.760756] [ 68.760756] Allocated by task 279: [ 68.760756] kasan_save_stack+0x1e/0x40 [ ---truncated---(CVE-2022-49505)

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

usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait

While performing fast composition switch, there is a possibility that the process of ffs_ep0_write/ffs_ep0_read get into a race condition due to ep0req being freed up from functionfs_unbind.

Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait by taking a lock &ffs->ev.waitq.lock. However, the functionfs_unbind isn't bounded so it can go ahead and mark the ep0req to NULL, and since there is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free.

Fix this by making a serialized execution between the two functions using a mutex_lock(ffs->mutex).(CVE-2022-49755)

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

dm ioctl: fix misbehavior if list_versions races with module loading

__list_versions will first estimate the required space using the "dm_target_iterate(list_version_get_needed, &needed)" call and then will fill the space using the "dm_target_iterate(list_version_get_info, &iter_info)" call. Each of these calls locks the targets using the "down_read(&_lock)" and "up_read(&_lock)" calls, however between the first and second "dm_target_iterate" there is no lock held and the target modules can be loaded at this point, so the second "dm_target_iterate" call may need more space than what was the first "dm_target_iterate" returned.

The code tries to handle this overflow (see the beginning of list_version_get_info), however this handling is incorrect.

The code sets "param->data_size = param->data_start + needed" and "iter_info.end = (char *)vers+len" - "needed" is the size returned by the first dm_target_iterate call; "len" is the size of the buffer allocated by userspace.

"len" may be greater than "needed"; in this case, the code will write up to "len" bytes into the buffer, however param->data_size is set to "needed", so it may write data past the param->data_size value. The ioctl interface copies only up to param->data_size into userspace, thus part of the result will be truncated.

Fix this bug by setting "iter_info.end = (char *)vers + needed;" - this guarantees that the second "dm_target_iterate" call will write only up to the "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it overflows the "needed" space - in this case, userspace will allocate a larger buffer and retry.

Note that there is also a bug in list_version_get_needed - we need to add "strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)".(CVE-2022-49771)

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

ata: libata-transport: fix double ata_host_put() in ata_tport_add()

In the error path in ata_tport_add(), when calling put_device(), ata_tport_release() is called, it will put the refcount of 'ap->host'.

And then ata_host_put() is called again, the refcount is decreased to 0, ata_host_release() is called, all ports are freed and set to null.

When unbinding the device after failure, ata_host_stop() is called to release the resources, it leads a null-ptr-deref(), because all the ports all freed and null.

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ata_host_stop+0x3c/0x84 [libata] lr : release_nodes+0x64/0xd0 Call trace: ata_host_stop+0x3c/0x84 [libata] release_nodes+0x64/0xd0 devres_release_all+0xbc/0x1b0 device_unbind_cleanup+0x20/0x70 really_probe+0x158/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __driver_attach+0xb4/0x220 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x40 bus_add_driver+0x184/0x240 driver_register+0x80/0x13c __pci_register_driver+0x4c/0x60 ahci_pci_driver_init+0x30/0x1000 [ahci]

Fix this by removing redundant ata_host_put() in the error path.(CVE-2022-49826)

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

ASoC: core: Fix use-after-free in snd_soc_exit()

KASAN reports a use-after-free:

BUG: KASAN: use-after-free in device_del+0xb5b/0xc60 Read of size 8 at addr ffff888008655050 by task rmmod/387 CPU: 2 PID: 387 Comm: rmmod Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl+0x79/0x9a print_report+0x17f/0x47b kasan_report+0xbb/0xf0 device_del+0xb5b/0xc60 platform_device_del.part.0+0x24/0x200 platform_device_unregister+0x2e/0x40 snd_soc_exit+0xa/0x22 [snd_soc_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK>

It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail, but its ret is ignored, which makes soc_dummy_dev unregistered twice.

snd_soc_init() snd_soc_util_init() platform_device_register_simple(soc_dummy_dev) platform_driver_register() # fail platform_device_unregister(soc_dummy_dev) platform_driver_register() # success ... snd_soc_exit() snd_soc_util_exit() # soc_dummy_dev will be unregistered for second time

To fix it, handle error and stop snd_soc_init() when util_init() fail. Also clean debugfs when util_init() or driver_register() fail.(CVE-2022-49842)

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

nilfs2: fix deadlock in nilfs_count_free_blocks()

A semaphore deadlock can occur if nilfs_get_block() detects metadata corruption while locating data blocks and a superblock writeback occurs at the same time:

task 1 task 2 ------ ------ * A file operation * nilfs_truncate() nilfs_get_block() down_read(rwsem A) <-- nilfs_bmap_lookup_contig() ... generic_shutdown_super() nilfs_put_super() * Prepare to write superblock * down_write(rwsem B) <-- nilfs_cleanup_super() * Detect b-tree corruption * nilfs_set_log_cursor() nilfs_bmap_convert_error() nilfs_count_free_blocks() __nilfs_error() down_read(rwsem A) <-- nilfs_set_error() down_write(rwsem B) <--

                       *** DEADLOCK ***

Here, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)->mi_sem) and then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata corruption, __nilfs_error() is called from nilfs_bmap_convert_error() inside the lock section.

Since __nilfs_error() calls nilfs_set_error() unless the filesystem is read-only and nilfs_set_error() attempts to writelock rwsem B (= nilfs->ns_sem) to write back superblock exclusively, hierarchical lock acquisition occurs in the order rwsem A -> rwsem B.

Now, if another task starts updating the superblock, it may writelock rwsem B during the lock sequence above, and can deadlock trying to readlock rwsem A in nilfs_count_free_blocks().

However, there is actually no need to take rwsem A in nilfs_count_free_blocks() because it, within the lock section, only reads a single integer data on a shared struct with nilfs_sufile_get_ncleansegs(). This has been the case after commit aa474a220180 ("nilfs2: add local variable to cache the number of clean segments"), that is, even before this bug was introduced.

So, this resolves the deadlock problem by just not taking the semaphore in nilfs_count_free_blocks().(CVE-2022-49850)

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

mISDN: fix possible memory leak in mISDN_register_device()

Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, add put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0.

Set device class before put_device() to avoid null release() function WARN message in device_release().(CVE-2022-49915)

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

drm/amdkfd: Fix an illegal memory access

In the kfd_wait_on_events() function, the kfd_event_waiter structure is allocated by alloc_event_waiters(), but the event field of the waiter structure is not initialized; When copy_from_user() fails in the kfd_wait_on_events() function, it will enter exception handling to release the previously allocated memory of the waiter structure; Due to the event field of the waiters structure being accessed in the free_waiters() function, this results in illegal memory access and system crash, here is the crash log:

localhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0 localhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082 localhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000 localhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0 localhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64 localhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002 localhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698 localhost kernel: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 localhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0 localhost kernel: Call Trace: localhost kernel: _raw_spin_lock_irqsave+0x30/0x40 localhost kernel: remove_wait_queue+0x12/0x50 localhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu] localhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu] localhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: __x64_sys_ioctl+0x8e/0xd0 localhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0 localhost kernel: do_syscall_64+0x33/0x80 localhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 localhost kernel: RIP: 0033:0x152a4dff68d7

Allocate the structure with kcalloc, and remove redundant 0-initialization and a redundant loop condition check.(CVE-2023-53090)

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

nvmet: avoid potential UAF in nvmet_req_complete()

An nvme target ->queue_response() operation implementation may free the request passed as argument. Such implementation potentially could result in a use after free of the request pointer when percpu_ref_put() is called in nvmet_req_complete().

Avoid such problem by using a local variable to save the sq pointer before calling __nvmet_req_complete(), thus avoiding dereferencing the req pointer after that function call.(CVE-2023-53116)

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

proc: fix UAF in proc_get_inode()

Fix race between rmmod and /proc/XXX's inode instantiation.

The bug is that pde->proc_ops don't belong to /proc, it belongs to a module, therefore dereferencing it after /proc entry has been registered is a bug unless use_pde/unuse_pde() pair has been used.

use_pde/unuse_pde can be avoided (2 atomic ops!) because pde->proc_ops never changes so information necessary for inode instantiation can be saved before proc_register() in PDE itself and used later, avoiding pde->proc_ops->... dereference.

  rmmod                         lookup

sys_delete_module proc_lookup_de pde_get(de); proc_get_inode(dir->i_sb, de); mod->exit() proc_remove remove_proc_subtree proc_entry_rundown(de); free_module(mod);

                           if (S_ISREG(inode-&gt;i_mode))
                         if (de-&gt;proc_ops-&gt;proc_read_iter)
                       --&gt; As module is already freed, will trigger UAF

BUG: unable to handle page fault for address: fffffbfff80a702b PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:proc_get_inode+0x302/0x6e0 RSP: 0018:ffff88811c837998 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007 RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158 RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20 R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0 R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001 FS: 00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> proc_lookup_de+0x11f/0x2e0 __lookup_slow+0x188/0x350 walk_component+0x2ab/0x4f0 path_lookupat+0x120/0x660 filename_lookup+0x1ce/0x560 vfs_statx+0xac/0x150 __do_sys_newstat+0x96/0x110 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e

adobriyan@gmail.com: don't do 2 atomic ops on the common path

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": [
          "bpftool-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2505.3.0.0327.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2505.3.0.0327.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2505.3.0.0327.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-2505.3.0.0327.oe2003sp4"
            }
          ],
          "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\nBluetooth: Fix use after free in hci_send_acl\n\nThis fixes the following trace caused by receiving\nHCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without\nfirst checking if conn-\u0026gt;type is in fact AMP_LINK and in case it is\ndo properly cleanup upper layers with hci_disconn_cfm:\n\n ==================================================================\n    BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50\n    Read of size 8 at addr ffff88800e404818 by task bluetoothd/142\n\n    CPU: 0 PID: 142 Comm: bluetoothd Not tainted\n    5.17.0-rc5-00006-gda4022eeac1a #7\n    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n    rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n    Call Trace:\n     \u0026lt;TASK\u0026gt;\n     dump_stack_lvl+0x45/0x59\n     print_address_description.constprop.0+0x1f/0x150\n     kasan_report.cold+0x7f/0x11b\n     hci_send_acl+0xaba/0xc50\n     l2cap_do_send+0x23f/0x3d0\n     l2cap_chan_send+0xc06/0x2cc0\n     l2cap_sock_sendmsg+0x201/0x2b0\n     sock_sendmsg+0xdc/0x110\n     sock_write_iter+0x20f/0x370\n     do_iter_readv_writev+0x343/0x690\n     do_iter_write+0x132/0x640\n     vfs_writev+0x198/0x570\n     do_writev+0x202/0x280\n     do_syscall_64+0x38/0x90\n     entry_SYSCALL_64_after_hwframe+0x44/0xae\n    RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014\n    Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3\n    0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05\n    \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10\n    RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015\n    RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77\n    R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580\n    RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001\n    \u0026lt;/TASK\u0026gt;\n    R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0\n\n    Allocated by task 45:\n        kasan_save_stack+0x1e/0x40\n        __kasan_kmalloc+0x81/0xa0\n        hci_chan_create+0x9a/0x2f0\n        l2cap_conn_add.part.0+0x1a/0xdc0\n        l2cap_connect_cfm+0x236/0x1000\n        le_conn_complete_evt+0x15a7/0x1db0\n        hci_le_conn_complete_evt+0x226/0x2c0\n        hci_le_meta_evt+0x247/0x450\n        hci_event_packet+0x61b/0xe90\n        hci_rx_work+0x4d5/0xc50\n        process_one_work+0x8fb/0x15a0\n        worker_thread+0x576/0x1240\n        kthread+0x29d/0x340\n        ret_from_fork+0x1f/0x30\n\n    Freed by task 45:\n        kasan_save_stack+0x1e/0x40\n        kasan_set_track+0x21/0x30\n        kasan_set_free_info+0x20/0x30\n        __kasan_slab_free+0xfb/0x130\n        kfree+0xac/0x350\n        hci_conn_cleanup+0x101/0x6a0\n        hci_conn_del+0x27e/0x6c0\n        hci_disconn_phylink_complete_evt+0xe0/0x120\n        hci_event_packet+0x812/0xe90\n        hci_rx_work+0x4d5/0xc50\n        process_one_work+0x8fb/0x15a0\n        worker_thread+0x576/0x1240\n        kthread+0x29d/0x340\n        ret_from_fork+0x1f/0x30\n\n    The buggy address belongs to the object at ffff88800c0f0500\n    The buggy address is located 24 bytes inside of\n    which belongs to the cache kmalloc-128 of size 128\n    The buggy address belongs to the page:\n    128-byte region [ffff88800c0f0500, ffff88800c0f0580)\n    flags: 0x100000000000200(slab|node=0|zone=1)\n    page:00000000fe45cd86 refcount:1 mapcount:0\n    mapping:0000000000000000 index:0x0 pfn:0xc0f0\n    raw: 0000000000000000 0000000080100010 00000001ffffffff\n    0000000000000000\n    raw: 0100000000000200 ffffea00003a2c80 dead000000000004\n    ffff8880078418c0\n    page dumped because: kasan: bad access detected\n    ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc\n    Memory state around the buggy address:\n    \u0026gt;ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n    ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n    ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n                   \n---truncated---(CVE-2022-49111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFC: NULL out the dev-\u0026gt;rfkill to prevent UAF\n\nCommit 3e3b5dfcd16a (\u0026quot;NFC: reorder the logic in nfc_{un,}register_device\u0026quot;)\nassumes the device_is_registered() in function nfc_dev_up() will help\nto check when the rfkill is unregistered. However, this check only\ntake effect when device_del(\u0026amp;dev-\u0026gt;dev) is done in nfc_unregister_device().\nHence, the rfkill object is still possible be dereferenced.\n\nThe crash trace in latest kernel (5.18-rc2):\n\n[   68.760105] ==================================================================\n[   68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750\n[   68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313\n[   68.760756]\n[   68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4\n[   68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[   68.760756] Call Trace:\n[   68.760756]  \u0026lt;TASK\u0026gt;\n[   68.760756]  dump_stack_lvl+0x57/0x7d\n[   68.760756]  print_report.cold+0x5e/0x5db\n[   68.760756]  ? __lock_acquire+0x3ec1/0x6750\n[   68.760756]  kasan_report+0xbe/0x1c0\n[   68.760756]  ? __lock_acquire+0x3ec1/0x6750\n[   68.760756]  __lock_acquire+0x3ec1/0x6750\n[   68.760756]  ? lockdep_hardirqs_on_prepare+0x410/0x410\n[   68.760756]  ? register_lock_class+0x18d0/0x18d0\n[   68.760756]  lock_acquire+0x1ac/0x4f0\n[   68.760756]  ? rfkill_blocked+0xe/0x60\n[   68.760756]  ? lockdep_hardirqs_on_prepare+0x410/0x410\n[   68.760756]  ? mutex_lock_io_nested+0x12c0/0x12c0\n[   68.760756]  ? nla_get_range_signed+0x540/0x540\n[   68.760756]  ? _raw_spin_lock_irqsave+0x4e/0x50\n[   68.760756]  _raw_spin_lock_irqsave+0x39/0x50\n[   68.760756]  ? rfkill_blocked+0xe/0x60\n[   68.760756]  rfkill_blocked+0xe/0x60\n[   68.760756]  nfc_dev_up+0x84/0x260\n[   68.760756]  nfc_genl_dev_up+0x90/0xe0\n[   68.760756]  genl_family_rcv_msg_doit+0x1f4/0x2f0\n[   68.760756]  ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230\n[   68.760756]  ? security_capable+0x51/0x90\n[   68.760756]  genl_rcv_msg+0x280/0x500\n[   68.760756]  ? genl_get_cmd+0x3c0/0x3c0\n[   68.760756]  ? lock_acquire+0x1ac/0x4f0\n[   68.760756]  ? nfc_genl_dev_down+0xe0/0xe0\n[   68.760756]  ? lockdep_hardirqs_on_prepare+0x410/0x410\n[   68.760756]  netlink_rcv_skb+0x11b/0x340\n[   68.760756]  ? genl_get_cmd+0x3c0/0x3c0\n[   68.760756]  ? netlink_ack+0x9c0/0x9c0\n[   68.760756]  ? netlink_deliver_tap+0x136/0xb00\n[   68.760756]  genl_rcv+0x1f/0x30\n[   68.760756]  netlink_unicast+0x430/0x710\n[   68.760756]  ? memset+0x20/0x40\n[   68.760756]  ? netlink_attachskb+0x740/0x740\n[   68.760756]  ? __build_skb_around+0x1f4/0x2a0\n[   68.760756]  netlink_sendmsg+0x75d/0xc00\n[   68.760756]  ? netlink_unicast+0x710/0x710\n[   68.760756]  ? netlink_unicast+0x710/0x710\n[   68.760756]  sock_sendmsg+0xdf/0x110\n[   68.760756]  __sys_sendto+0x19e/0x270\n[   68.760756]  ? __ia32_sys_getpeername+0xa0/0xa0\n[   68.760756]  ? fd_install+0x178/0x4c0\n[   68.760756]  ? fd_install+0x195/0x4c0\n[   68.760756]  ? kernel_fpu_begin_mask+0x1c0/0x1c0\n[   68.760756]  __x64_sys_sendto+0xd8/0x1b0\n[   68.760756]  ? lockdep_hardirqs_on+0xbf/0x130\n[   68.760756]  ? syscall_enter_from_user_mode+0x1d/0x50\n[   68.760756]  do_syscall_64+0x3b/0x90\n[   68.760756]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[   68.760756] RIP: 0033:0x7f67fb50e6b3\n...\n[   68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c\n[   68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3\n[   68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003\n[   68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c\n[   68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e\n[   68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003\n\n[   68.760756]  \u0026lt;/TASK\u0026gt;\n[   68.760756]\n[   68.760756] Allocated by task 279:\n[   68.760756]  kasan_save_stack+0x1e/0x40\n[\n---truncated---(CVE-2022-49505)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait\n\nWhile performing fast composition switch, there is a possibility that the\nprocess of ffs_ep0_write/ffs_ep0_read get into a race condition\ndue to ep0req being freed up from functionfs_unbind.\n\nConsider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait\nby taking a lock \u0026amp;ffs-\u0026gt;ev.waitq.lock. However, the functionfs_unbind isn\u0026apos;t\nbounded so it can go ahead and mark the ep0req to NULL, and since there\nis no NULL check in ffs_ep0_queue_wait we will end up in use-after-free.\n\nFix this by making a serialized execution between the two functions using\na mutex_lock(ffs-\u0026gt;mutex).(CVE-2022-49755)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm ioctl: fix misbehavior if list_versions races with module loading\n\n__list_versions will first estimate the required space using the\n\u0026quot;dm_target_iterate(list_version_get_needed, \u0026amp;needed)\u0026quot; call and then will\nfill the space using the \u0026quot;dm_target_iterate(list_version_get_info,\n\u0026amp;iter_info)\u0026quot; call. Each of these calls locks the targets using the\n\u0026quot;down_read(\u0026amp;_lock)\u0026quot; and \u0026quot;up_read(\u0026amp;_lock)\u0026quot; calls, however between the first\nand second \u0026quot;dm_target_iterate\u0026quot; there is no lock held and the target\nmodules can be loaded at this point, so the second \u0026quot;dm_target_iterate\u0026quot;\ncall may need more space than what was the first \u0026quot;dm_target_iterate\u0026quot;\nreturned.\n\nThe code tries to handle this overflow (see the beginning of\nlist_version_get_info), however this handling is incorrect.\n\nThe code sets \u0026quot;param-\u0026gt;data_size = param-\u0026gt;data_start + needed\u0026quot; and\n\u0026quot;iter_info.end = (char *)vers+len\u0026quot; - \u0026quot;needed\u0026quot; is the size returned by the\nfirst dm_target_iterate call; \u0026quot;len\u0026quot; is the size of the buffer allocated by\nuserspace.\n\n\u0026quot;len\u0026quot; may be greater than \u0026quot;needed\u0026quot;; in this case, the code will write up\nto \u0026quot;len\u0026quot; bytes into the buffer, however param-\u0026gt;data_size is set to\n\u0026quot;needed\u0026quot;, so it may write data past the param-\u0026gt;data_size value. The ioctl\ninterface copies only up to param-\u0026gt;data_size into userspace, thus part of\nthe result will be truncated.\n\nFix this bug by setting \u0026quot;iter_info.end = (char *)vers + needed;\u0026quot; - this\nguarantees that the second \u0026quot;dm_target_iterate\u0026quot; call will write only up to\nthe \u0026quot;needed\u0026quot; buffer and it will exit with \u0026quot;DM_BUFFER_FULL_FLAG\u0026quot; if it\noverflows the \u0026quot;needed\u0026quot; space - in this case, userspace will allocate a\nlarger buffer and retry.\n\nNote that there is also a bug in list_version_get_needed - we need to add\n\u0026quot;strlen(tt-\u0026gt;name) + 1\u0026quot; to the needed size, not \u0026quot;strlen(tt-\u0026gt;name)\u0026quot;.(CVE-2022-49771)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix double ata_host_put() in ata_tport_add()\n\nIn the error path in ata_tport_add(), when calling put_device(),\nata_tport_release() is called, it will put the refcount of \u0026apos;ap-\u0026gt;host\u0026apos;.\n\nAnd then ata_host_put() is called again, the refcount is decreased\nto 0, ata_host_release() is called, all ports are freed and set to\nnull.\n\nWhen unbinding the device after failure, ata_host_stop() is called\nto release the resources, it leads a null-ptr-deref(), because all\nthe ports all freed and null.\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000008\nCPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G            E      6.1.0-rc3+ #8\npstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : ata_host_stop+0x3c/0x84 [libata]\nlr : release_nodes+0x64/0xd0\nCall trace:\n ata_host_stop+0x3c/0x84 [libata]\n release_nodes+0x64/0xd0\n devres_release_all+0xbc/0x1b0\n device_unbind_cleanup+0x20/0x70\n really_probe+0x158/0x320\n __driver_probe_device+0x84/0x120\n driver_probe_device+0x44/0x120\n __driver_attach+0xb4/0x220\n bus_for_each_dev+0x78/0xdc\n driver_attach+0x2c/0x40\n bus_add_driver+0x184/0x240\n driver_register+0x80/0x13c\n __pci_register_driver+0x4c/0x60\n ahci_pci_driver_init+0x30/0x1000 [ahci]\n\nFix this by removing redundant ata_host_put() in the error path.(CVE-2022-49826)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Fix use-after-free in snd_soc_exit()\n\nKASAN reports a use-after-free:\n\nBUG: KASAN: use-after-free in device_del+0xb5b/0xc60\nRead of size 8 at addr ffff888008655050 by task rmmod/387\nCPU: 2 PID: 387 Comm: rmmod\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x79/0x9a\nprint_report+0x17f/0x47b\nkasan_report+0xbb/0xf0\ndevice_del+0xb5b/0xc60\nplatform_device_del.part.0+0x24/0x200\nplatform_device_unregister+0x2e/0x40\nsnd_soc_exit+0xa/0x22 [snd_soc_core]\n__do_sys_delete_module.constprop.0+0x34f/0x5b0\ndo_syscall_64+0x3a/0x90\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n...\n\u0026lt;/TASK\u0026gt;\n\nIt\u0026apos;s bacause in snd_soc_init(), snd_soc_util_init() is possble to fail,\nbut its ret is ignored, which makes soc_dummy_dev unregistered twice.\n\nsnd_soc_init()\n    snd_soc_util_init()\n        platform_device_register_simple(soc_dummy_dev)\n        platform_driver_register() # fail\n    \tplatform_device_unregister(soc_dummy_dev)\n    platform_driver_register() # success\n...\nsnd_soc_exit()\n    snd_soc_util_exit()\n    # soc_dummy_dev will be unregistered for second time\n\nTo fix it, handle error and stop snd_soc_init() when util_init() fail.\nAlso clean debugfs when util_init() or driver_register() fail.(CVE-2022-49842)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix deadlock in nilfs_count_free_blocks()\n\nA semaphore deadlock can occur if nilfs_get_block() detects metadata\ncorruption while locating data blocks and a superblock writeback occurs at\nthe same time:\n\ntask 1                               task 2\n------                               ------\n* A file operation *\nnilfs_truncate()\n  nilfs_get_block()\n    down_read(rwsem A) \u0026lt;--\n    nilfs_bmap_lookup_contig()\n      ...                            generic_shutdown_super()\n                                       nilfs_put_super()\n                                         * Prepare to write superblock *\n                                         down_write(rwsem B) \u0026lt;--\n                                         nilfs_cleanup_super()\n      * Detect b-tree corruption *         nilfs_set_log_cursor()\n      nilfs_bmap_convert_error()             nilfs_count_free_blocks()\n        __nilfs_error()                        down_read(rwsem A) \u0026lt;--\n          nilfs_set_error()\n            down_write(rwsem B) \u0026lt;--\n\n                           *** DEADLOCK ***\n\nHere, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)-\u0026gt;mi_sem)\nand then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata\ncorruption, __nilfs_error() is called from nilfs_bmap_convert_error()\ninside the lock section.\n\nSince __nilfs_error() calls nilfs_set_error() unless the filesystem is\nread-only and nilfs_set_error() attempts to writelock rwsem B (=\nnilfs-\u0026gt;ns_sem) to write back superblock exclusively, hierarchical lock\nacquisition occurs in the order rwsem A -\u0026gt; rwsem B.\n\nNow, if another task starts updating the superblock, it may writelock\nrwsem B during the lock sequence above, and can deadlock trying to\nreadlock rwsem A in nilfs_count_free_blocks().\n\nHowever, there is actually no need to take rwsem A in\nnilfs_count_free_blocks() because it, within the lock section, only reads\na single integer data on a shared struct with\nnilfs_sufile_get_ncleansegs().  This has been the case after commit\naa474a220180 (\u0026quot;nilfs2: add local variable to cache the number of clean\nsegments\u0026quot;), that is, even before this bug was introduced.\n\nSo, this resolves the deadlock problem by just not taking the semaphore in\nnilfs_count_free_blocks().(CVE-2022-49850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmISDN: fix possible memory leak in mISDN_register_device()\n\nAfer commit 1fa5ae857bb1 (\u0026quot;driver core: get rid of struct device\u0026apos;s\nbus_id string array\u0026quot;), the name of device is allocated dynamically,\nadd put_device() to give up the reference, so that the name can be\nfreed in kobject_cleanup() when the refcount is 0.\n\nSet device class before put_device() to avoid null release() function\nWARN message in device_release().(CVE-2022-49915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix an illegal memory access\n\nIn the kfd_wait_on_events() function, the kfd_event_waiter structure is\nallocated by alloc_event_waiters(), but the event field of the waiter\nstructure is not initialized; When copy_from_user() fails in the\nkfd_wait_on_events() function, it will enter exception handling to\nrelease the previously allocated memory of the waiter structure;\nDue to the event field of the waiters structure being accessed\nin the free_waiters() function, this results in illegal memory access\nand system crash, here is the crash log:\n\nlocalhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0\nlocalhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082\nlocalhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000\nlocalhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0\nlocalhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64\nlocalhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002\nlocalhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698\nlocalhost kernel: FS:  0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000\nlocalhost kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nlocalhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0\nlocalhost kernel: Call Trace:\nlocalhost kernel: _raw_spin_lock_irqsave+0x30/0x40\nlocalhost kernel: remove_wait_queue+0x12/0x50\nlocalhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu]\nlocalhost kernel: ? ftrace_graph_caller+0xa0/0xa0\nlocalhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu]\nlocalhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu]\nlocalhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu]\nlocalhost kernel: ? ftrace_graph_caller+0xa0/0xa0\nlocalhost kernel: __x64_sys_ioctl+0x8e/0xd0\nlocalhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0\nlocalhost kernel: do_syscall_64+0x33/0x80\nlocalhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9\nlocalhost kernel: RIP: 0033:0x152a4dff68d7\n\nAllocate the structure with kcalloc, and remove redundant 0-initialization\nand a redundant loop condition check.(CVE-2023-53090)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: avoid potential UAF in nvmet_req_complete()\n\nAn nvme target -\u0026gt;queue_response() operation implementation may free the\nrequest passed as argument. Such implementation potentially could result\nin a use after free of the request pointer when percpu_ref_put() is\ncalled in nvmet_req_complete().\n\nAvoid such problem by using a local variable to save the sq pointer\nbefore calling __nvmet_req_complete(), thus avoiding dereferencing the\nreq pointer after that function call.(CVE-2023-53116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nproc: fix UAF in proc_get_inode()\n\nFix race between rmmod and /proc/XXX\u0026apos;s inode instantiation.\n\nThe bug is that pde-\u0026gt;proc_ops don\u0026apos;t belong to /proc, it belongs to a\nmodule, therefore dereferencing it after /proc entry has been registered\nis a bug unless use_pde/unuse_pde() pair has been used.\n\nuse_pde/unuse_pde can be avoided (2 atomic ops!) because pde-\u0026gt;proc_ops\nnever changes so information necessary for inode instantiation can be\nsaved _before_ proc_register() in PDE itself and used later, avoiding\npde-\u0026gt;proc_ops-\u0026gt;...  dereference.\n\n      rmmod                         lookup\nsys_delete_module\n                         proc_lookup_de\n\t\t\t   pde_get(de);\n\t\t\t   proc_get_inode(dir-\u0026gt;i_sb, de);\n  mod-\u0026gt;exit()\n    proc_remove\n      remove_proc_subtree\n       proc_entry_rundown(de);\n  free_module(mod);\n\n                               if (S_ISREG(inode-\u0026gt;i_mode))\n\t                         if (de-\u0026gt;proc_ops-\u0026gt;proc_read_iter)\n                           --\u0026gt; As module is already freed, will trigger UAF\n\nBUG: unable to handle page fault for address: fffffbfff80a702b\nPGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nRIP: 0010:proc_get_inode+0x302/0x6e0\nRSP: 0018:ffff88811c837998 EFLAGS: 00010a06\nRAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007\nRDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158\nRBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20\nR10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0\nR13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001\nFS:  00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n proc_lookup_de+0x11f/0x2e0\n __lookup_slow+0x188/0x350\n walk_component+0x2ab/0x4f0\n path_lookupat+0x120/0x660\n filename_lookup+0x1ce/0x560\n vfs_statx+0xac/0x150\n __do_sys_newstat+0x96/0x110\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n[adobriyan@gmail.com: don\u0026apos;t do 2 atomic ops on the common path](CVE-2025-21999)",
  "id": "OESA-2025-1513",
  "modified": "2026-08-06T11:08:36Z",
  "published": "2025-05-16T11:08:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1513"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49111"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49505"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49755"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49771"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49826"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49842"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49850"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49915"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53090"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53116"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21999"
    }
  ],
  "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-2022-49111",
    "CVE-2022-49505",
    "CVE-2022-49755",
    "CVE-2022-49771",
    "CVE-2022-49826",
    "CVE-2022-49842",
    "CVE-2022-49850",
    "CVE-2022-49915",
    "CVE-2023-53090",
    "CVE-2023-53116",
    "CVE-2025-21999"
  ]
}



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.