CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48931 – configfs: fix a race in configfs_{,un}register_subsystem()
https://notcve.org/view.php?id=CVE-2022-48931
In the Linux kernel, the following vulnerability has been resolved: configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex. • https://git.kernel.org/stable/c/7063fbf2261194f72ee75afca67b3b38b554b5fa https://git.kernel.org/stable/c/40805099af11f68c5ca7dbcfacf455da8f99f622 https://git.kernel.org/stable/c/d1654de19d42f513b6cfe955cc77e7f427e05a77 https://git.kernel.org/stable/c/a37024f7757c25550accdebf49e497ad6ae239fe https://git.kernel.org/stable/c/b7e2b91fcb5c78c414e33dc8d50642e307ca0c5a https://git.kernel.org/stable/c/a7ab53d3c27dfe83bb594456b9f38a37796ec39b https://git.kernel.org/stable/c/e7a66dd2687758718eddd79b542a95cf3aa488cc https://git.kernel.org/stable/c/3aadfd46858b1f64d4d6a0654b863e21a •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48930 – RDMA/ib_srp: Fix a deadlock
https://notcve.org/view.php?id=CVE-2022-48930
In the Linux kernel, the following vulnerability has been resolved: RDMA/ib_srp: Fix a deadlock Remove the flush_workqueue(system_long_wq) call since flushing system_long_wq is deadlock-prone and since that call is redundant with a preceding cancel_work_sync() • https://git.kernel.org/stable/c/ef6c49d87c3418c442a22e55e3ce2f91b163d69e https://git.kernel.org/stable/c/8cc342508f9e7fdccd2e9758ae9d52aff72dab7f https://git.kernel.org/stable/c/4752fafb461821f8c8581090c923ababba68c5bd https://git.kernel.org/stable/c/d7997d19dfa7001ca41e971cd9efd091bb195b51 https://git.kernel.org/stable/c/901206f71e6ad2b2e7accefc5199a438d173c25f https://git.kernel.org/stable/c/99eb8d694174c777558dc902d575d1997d5ca650 https://git.kernel.org/stable/c/c8b56e51aa91b8e7df3a98388dce3fdabd15c1d4 https://git.kernel.org/stable/c/98d056603ce55ceb90631b3927151c190 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48928 – iio: adc: men_z188_adc: Fix a resource leak in an error handling path
https://notcve.org/view.php?id=CVE-2022-48928
In the Linux kernel, the following vulnerability has been resolved: iio: adc: men_z188_adc: Fix a resource leak in an error handling path If iio_device_register() fails, a previous ioremap() is left unbalanced. Update the error handling path and add the missing iounmap() call, as already done in the remove function. • https://git.kernel.org/stable/c/74aeac4da66fbfa246edbfc849002eac9b5af9ca https://git.kernel.org/stable/c/0f88722313645a903f4d420ba61ddc690ec2481d https://git.kernel.org/stable/c/c5723b422f564af15f2e3bc0592fd6376a0a6c45 https://git.kernel.org/stable/c/53d43a9c8dd224e66559fe86af1e473802c7130e https://git.kernel.org/stable/c/ce1076b33e299dc8d270e4450a420a18bfb3e190 https://git.kernel.org/stable/c/1aa12ecfdcbafebc218910ec47acf6262e600cf5 https://git.kernel.org/stable/c/fe73477802981bd0d0d70f2b22f109bcca801bdb https://git.kernel.org/stable/c/d6ed5426a7fad36cf928c244483ba24e7 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48926 – usb: gadget: rndis: add spinlock for rndis response list
https://notcve.org/view.php?id=CVE-2022-48926
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: rndis: add spinlock for rndis response list There's no lock for rndis response list. It could cause list corruption if there're two different list_add at the same time like below. It's better to add in rndis_add_response / rndis_free_response / rndis_get_next_response to prevent any race condition on response list. [ 361.894299] [1: irq/191-dwc3:16979] list_add corruption. next->prev should be prev (ffffff80651764d0), but was ffffff883dc36f80. (next=ffffff80651764d0). [ 361.904380] [1: irq/191-dwc3:16979] Call trace: [ 361.904391] [1: irq/191-dwc3:16979] __list_add_valid+0x74/0x90 [ 361.904401] [1: irq/191-dwc3:16979] rndis_msg_parser+0x168/0x8c0 [ 361.904409] [1: irq/191-dwc3:16979] rndis_command_complete+0x24/0x84 [ 361.904417] [1: irq/191-dwc3:16979] usb_gadget_giveback_request+0x20/0xe4 [ 361.904426] [1: irq/191-dwc3:16979] dwc3_gadget_giveback+0x44/0x60 [ 361.904434] [1: irq/191-dwc3:16979] dwc3_ep0_complete_data+0x1e8/0x3a0 [ 361.904442] [1: irq/191-dwc3:16979] dwc3_ep0_interrupt+0x29c/0x3dc [ 361.904450] [1: irq/191-dwc3:16979] dwc3_process_event_entry+0x78/0x6cc [ 361.904457] [1: irq/191-dwc3:16979] dwc3_process_event_buf+0xa0/0x1ec [ 361.904465] [1: irq/191-dwc3:16979] dwc3_thread_interrupt+0x34/0x5c • https://git.kernel.org/stable/c/f6281af9d62e128aa6efad29cf7265062af114f2 https://git.kernel.org/stable/c/9f5d8ba538ef81cd86ea587ca3f8c77e26bea405 https://git.kernel.org/stable/c/669c2b178956718407af5631ccbc61c24413f038 https://git.kernel.org/stable/c/9f688aadede6b862a0a898792b1a35421c93636f https://git.kernel.org/stable/c/9ab652d41deab49848673c3dadb57ad338485376 https://git.kernel.org/stable/c/4ce247af3f30078d5b97554f1ae6200a0222c15a https://git.kernel.org/stable/c/da514063440b53a27309a4528b726f92c3cfe56f https://git.kernel.org/stable/c/33222d1571d7ce8c1c75f6b488f38968f •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48943 – KVM: x86/mmu: make apf token non-zero to fix bug
https://notcve.org/view.php?id=CVE-2022-48943
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: make apf token non-zero to fix bug In current async pagefault logic, when a page is ready, KVM relies on kvm_arch_can_dequeue_async_page_present() to determine whether to deliver a READY event to the Guest. This function test token value of struct kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a READY event is finished by Guest. If value is zero meaning that a READY event is done, so the KVM can deliver another. But the kvm_arch_setup_async_pf() may produce a valid token with zero value, which is confused with previous mention and may lead the loss of this READY event. This bug may cause task blocked forever in Guest: INFO: task stress:7532 blocked for more than 1254 seconds. Not tainted 5.10.0 #16 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:stress state:D stack: 0 pid: 7532 ppid: 1409 flags:0x00000080 Call Trace: __schedule+0x1e7/0x650 schedule+0x46/0xb0 kvm_async_pf_task_wait_schedule+0xad/0xe0 ? exit_to_user_mode_prepare+0x60/0x70 __kvm_handle_async_pf+0x4f/0xb0 ? asm_exc_page_fault+0x8/0x30 exc_page_fault+0x6f/0x110 ? • https://git.kernel.org/stable/c/72fdfc75d4217b32363cc80def3de2cb3fef3f02 https://git.kernel.org/stable/c/4c3644b6c96c5daa5149e5abddc07234eea47c7c https://git.kernel.org/stable/c/62040f5cd7d937de547836e747b6aa8212fec573 https://git.kernel.org/stable/c/6f3c1fc53d86d580d8d6d749c4af23705e4f6f79 •