Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand<br /> <br /> While trying to get the subpage blocksize tests running, I hit the<br /> following panic on generic/476<br /> <br /> assertion failed: PagePrivate(page) &amp;&amp; page-&gt;private, in fs/btrfs/subpage.c:229<br /> kernel BUG at fs/btrfs/subpage.c:229!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12<br /> Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023<br /> pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> pc : btrfs_subpage_assert+0xbc/0xf0<br /> lr : btrfs_subpage_assert+0xbc/0xf0<br /> Call trace:<br /> btrfs_subpage_assert+0xbc/0xf0<br /> btrfs_subpage_clear_checked+0x38/0xc0<br /> btrfs_page_clear_checked+0x48/0x98<br /> btrfs_truncate_block+0x5d0/0x6a8<br /> btrfs_cont_expand+0x5c/0x528<br /> btrfs_write_check.isra.0+0xf8/0x150<br /> btrfs_buffered_write+0xb4/0x760<br /> btrfs_do_write_iter+0x2f8/0x4b0<br /> btrfs_file_write_iter+0x1c/0x30<br /> do_iter_readv_writev+0xc8/0x158<br /> do_iter_write+0x9c/0x210<br /> vfs_iter_write+0x24/0x40<br /> iter_file_splice_write+0x224/0x390<br /> direct_splice_actor+0x38/0x68<br /> splice_direct_to_actor+0x12c/0x260<br /> do_splice_direct+0x90/0xe8<br /> generic_copy_file_range+0x50/0x90<br /> vfs_copy_file_range+0x29c/0x470<br /> __arm64_sys_copy_file_range+0xcc/0x498<br /> invoke_syscall.constprop.0+0x80/0xd8<br /> do_el0_svc+0x6c/0x168<br /> el0_svc+0x50/0x1b0<br /> el0t_64_sync_handler+0x114/0x120<br /> el0t_64_sync+0x194/0x198<br /> <br /> This happens because during btrfs_cont_expand we&amp;#39;ll get a page, set it<br /> as mapped, and if it&amp;#39;s not Uptodate we&amp;#39;ll read it. However between the<br /> read and re-locking the page we could have called release_folio() on the<br /> page, but left the page in the file mapping. release_folio() can clear<br /> the page private, and thus further down we blow up when we go to modify<br /> the subpage bits.<br /> <br /> Fix this by putting the set_page_extent_mapped() after the read. This<br /> is safe because read_folio() will call set_page_extent_mapped() before<br /> it does the read, and then if we clear page private but leave it on the<br /> mapping we&amp;#39;re completely safe re-setting set_page_extent_mapped(). With<br /> this patch I can now run generic/476 without panicing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: Fix detection of atomic context<br /> <br /> Current check for atomic context is not sufficient as<br /> z_erofs_decompressqueue_endio can be called under rcu lock<br /> from blk_mq_flush_plug_list(). See the stacktrace [1]<br /> <br /> In such case we should hand off the decompression work for async<br /> processing rather than trying to do sync decompression in current<br /> context. Patch fixes the detection by checking for<br /> rcu_read_lock_any_held() and while at it use more appropriate<br /> !in_task() check than in_atomic().<br /> <br /> Background: Historically erofs would always schedule a kworker for<br /> decompression which would incur the scheduling cost regardless of<br /> the context. But z_erofs_decompressqueue_endio() may not always<br /> be in atomic context and we could actually benefit from doing the<br /> decompression in z_erofs_decompressqueue_endio() if we are in<br /> thread context, for example when running with dm-verity.<br /> This optimization was later added in patch [2] which has shown<br /> improvement in performance benchmarks.<br /> <br /> ==============================================<br /> [1] Problem stacktrace<br /> [name:core&amp;]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291<br /> [name:core&amp;]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi<br /> [name:core&amp;]preempt_count: 0, expected: 0<br /> [name:core&amp;]RCU nest depth: 1, expected: 0<br /> CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1<br /> Hardware name: MT6897 (DT)<br /> Call trace:<br /> dump_backtrace+0x108/0x15c<br /> show_stack+0x20/0x30<br /> dump_stack_lvl+0x6c/0x8c<br /> dump_stack+0x20/0x48<br /> __might_resched+0x1fc/0x308<br /> __might_sleep+0x50/0x88<br /> mutex_lock+0x2c/0x110<br /> z_erofs_decompress_queue+0x11c/0xc10<br /> z_erofs_decompress_kickoff+0x110/0x1a4<br /> z_erofs_decompressqueue_endio+0x154/0x180<br /> bio_endio+0x1b0/0x1d8<br /> __dm_io_complete+0x22c/0x280<br /> clone_endio+0xe4/0x280<br /> bio_endio+0x1b0/0x1d8<br /> blk_update_request+0x138/0x3a4<br /> blk_mq_plug_issue_direct+0xd4/0x19c<br /> blk_mq_flush_plug_list+0x2b0/0x354<br /> __blk_flush_plug+0x110/0x160<br /> blk_finish_plug+0x30/0x4c<br /> read_pages+0x2fc/0x370<br /> page_cache_ra_unbounded+0xa4/0x23c<br /> page_cache_ra_order+0x290/0x320<br /> do_sync_mmap_readahead+0x108/0x2c0<br /> filemap_fault+0x19c/0x52c<br /> __do_fault+0xc4/0x114<br /> handle_mm_fault+0x5b4/0x1168<br /> do_page_fault+0x338/0x4b4<br /> do_translation_fault+0x40/0x60<br /> do_mem_abort+0x60/0xc8<br /> el0_da+0x4c/0xe0<br /> el0t_64_sync_handler+0xd4/0xfc<br /> el0t_64_sync+0x1a0/0x1a4<br /> <br /> [2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7921: fix kernel panic by accessing unallocated eeprom.data<br /> <br /> The MT7921 driver no longer uses eeprom.data, but the relevant code has not<br /> been removed completely since<br /> commit 16d98b548365 ("mt76: mt7921: rely on mcu_get_nic_capability").<br /> This could result in potential invalid memory access.<br /> <br /> To fix the kernel panic issue in mt7921, it is necessary to avoid accessing<br /> unallocated eeprom.data which can lead to invalid memory access.<br /> <br /> Furthermore, it is possible to entirely eliminate the<br /> mt7921_mcu_parse_eeprom function and solely depend on<br /> mt7921_mcu_parse_response to divide the RxD header.<br /> <br /> [2.702735] BUG: kernel NULL pointer dereference, address: 0000000000000550<br /> [2.702740] #PF: supervisor write access in kernel mode<br /> [2.702741] #PF: error_code(0x0002) - not-present page<br /> [2.702743] PGD 0 P4D 0<br /> [2.702747] Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> [2.702755] RIP: 0010:mt7921_mcu_parse_response+0x147/0x170 [mt7921_common]<br /> [2.702758] RSP: 0018:ffffae7c00fef828 EFLAGS: 00010286<br /> [2.702760] RAX: ffffa367f57be024 RBX: ffffa367cc7bf500 RCX: 0000000000000000<br /> [2.702762] RDX: 0000000000000550 RSI: 0000000000000000 RDI: ffffa367cc7bf500<br /> [2.702763] RBP: ffffae7c00fef840 R08: ffffa367cb167000 R09: 0000000000000005<br /> [2.702764] R10: 0000000000000000 R11: ffffffffc04702e4 R12: ffffa367e8329f40<br /> [2.702766] R13: 0000000000000000 R14: 0000000000000001 R15: ffffa367e8329f40<br /> [2.702768] FS: 000079ee6cf20c40(0000) GS:ffffa36b2f940000(0000) knlGS:0000000000000000<br /> [2.702769] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [2.702775] CR2: 0000000000000550 CR3: 00000001233c6004 CR4: 0000000000770ee0<br /> [2.702776] PKRU: 55555554<br /> [2.702777] Call Trace:<br /> [2.702782] mt76_mcu_skb_send_and_get_msg+0xc3/0x11e [mt76 ]<br /> [2.702785] mt7921_run_firmware+0x241/0x853 [mt7921_common ]<br /> [2.702789] mt7921e_mcu_init+0x2b/0x56 [mt7921e ]<br /> [2.702792] mt7921_register_device+0x2eb/0x5a5 [mt7921_common ]<br /> [2.702795] ? mt7921_irq_tasklet+0x1d4/0x1d4 [mt7921e ]<br /> [2.702797] mt7921_pci_probe+0x2d6/0x319 [mt7921e ]<br /> [2.702799] pci_device_probe+0x9f/0x12a

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix deadlock triggered by cancel_delayed_work_syn()<br /> <br /> The following LOCKDEP was detected:<br /> Workqueue: events smc_lgr_free_work [smc]<br /> WARNING: possible circular locking dependency detected<br /> 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted<br /> ------------------------------------------------------<br /> kworker/3:0/176251 is trying to acquire lock:<br /> 00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0},<br /> at: __flush_workqueue+0x7a/0x4f0<br /> but task is already holding lock:<br /> 0000037fffe97dc8 ((work_completion)(&amp;(&amp;lgr-&gt;free_work)-&gt;work)){+.+.}-{0:0},<br /> at: process_one_work+0x232/0x730<br /> which lock already depends on the new lock.<br /> the existing dependency chain (in reverse order) is:<br /> -&gt; #4 ((work_completion)(&amp;(&amp;lgr-&gt;free_work)-&gt;work)){+.+.}-{0:0}:<br /> __lock_acquire+0x58e/0xbd8<br /> lock_acquire.part.0+0xe2/0x248<br /> lock_acquire+0xac/0x1c8<br /> __flush_work+0x76/0xf0<br /> __cancel_work_timer+0x170/0x220<br /> __smc_lgr_terminate.part.0+0x34/0x1c0 [smc]<br /> smc_connect_rdma+0x15e/0x418 [smc]<br /> __smc_connect+0x234/0x480 [smc]<br /> smc_connect+0x1d6/0x230 [smc]<br /> __sys_connect+0x90/0xc0<br /> __do_sys_socketcall+0x186/0x370<br /> __do_syscall+0x1da/0x208<br /> system_call+0x82/0xb0<br /> -&gt; #3 (smc_client_lgr_pending){+.+.}-{3:3}:<br /> __lock_acquire+0x58e/0xbd8<br /> lock_acquire.part.0+0xe2/0x248<br /> lock_acquire+0xac/0x1c8<br /> __mutex_lock+0x96/0x8e8<br /> mutex_lock_nested+0x32/0x40<br /> smc_connect_rdma+0xa4/0x418 [smc]<br /> __smc_connect+0x234/0x480 [smc]<br /> smc_connect+0x1d6/0x230 [smc]<br /> __sys_connect+0x90/0xc0<br /> __do_sys_socketcall+0x186/0x370<br /> __do_syscall+0x1da/0x208<br /> system_call+0x82/0xb0<br /> -&gt; #2 (sk_lock-AF_SMC){+.+.}-{0:0}:<br /> __lock_acquire+0x58e/0xbd8<br /> lock_acquire.part.0+0xe2/0x248<br /> lock_acquire+0xac/0x1c8<br /> lock_sock_nested+0x46/0xa8<br /> smc_tx_work+0x34/0x50 [smc]<br /> process_one_work+0x30c/0x730<br /> worker_thread+0x62/0x420<br /> kthread+0x138/0x150<br /> __ret_from_fork+0x3c/0x58<br /> ret_from_fork+0xa/0x40<br /> -&gt; #1 ((work_completion)(&amp;(&amp;smc-&gt;conn.tx_work)-&gt;work)){+.+.}-{0:0}:<br /> __lock_acquire+0x58e/0xbd8<br /> lock_acquire.part.0+0xe2/0x248<br /> lock_acquire+0xac/0x1c8<br /> process_one_work+0x2bc/0x730<br /> worker_thread+0x62/0x420<br /> kthread+0x138/0x150<br /> __ret_from_fork+0x3c/0x58<br /> ret_from_fork+0xa/0x40<br /> -&gt; #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}:<br /> check_prev_add+0xd8/0xe88<br /> validate_chain+0x70c/0xb20<br /> __lock_acquire+0x58e/0xbd8<br /> lock_acquire.part.0+0xe2/0x248<br /> lock_acquire+0xac/0x1c8<br /> __flush_workqueue+0xaa/0x4f0<br /> drain_workqueue+0xaa/0x158<br /> destroy_workqueue+0x44/0x2d8<br /> smc_lgr_free+0x9e/0xf8 [smc]<br /> process_one_work+0x30c/0x730<br /> worker_thread+0x62/0x420<br /> kthread+0x138/0x150<br /> __ret_from_fork+0x3c/0x58<br /> ret_from_fork+0xa/0x40<br /> other info that might help us debug this:<br /> Chain exists of:<br /> (wq_completion)smc_tx_wq-00000000#2<br /> --&gt; smc_client_lgr_pending<br /> --&gt; (work_completion)(&amp;(&amp;lgr-&gt;free_work)-&gt;work)<br /> Possible unsafe locking scenario:<br /> CPU0 CPU1<br /> ---- ----<br /> lock((work_completion)(&amp;(&amp;lgr-&gt;free_work)-&gt;work));<br /> lock(smc_client_lgr_pending);<br /> lock((work_completion)<br /> (&amp;(&amp;lgr-&gt;free_work)-&gt;work));<br /> lock((wq_completion)smc_tx_wq-00000000#2);<br /> *** DEADLOCK ***<br /> 2 locks held by kworker/3:0/176251:<br /> #0: 0000000080183548<br /> ((wq_completion)events){+.+.}-{0:0},<br /> at: process_one_work+0x232/0x730<br /> #1: 0000037fffe97dc8<br /> ((work_completion)<br /> (&amp;(&amp;lgr-&gt;free_work)-&gt;work)){+.+.}-{0:0},<br /> at: process_one_work+0x232/0x730<br /> stack backtr<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: Fix kmemleak in watchdog_cdev_register<br /> <br /> kmemleak reports memory leaks in watchdog_dev_register, as follows:<br /> unreferenced object 0xffff888116233000 (size 2048):<br /> comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s)<br /> hex dump (first 32 bytes):<br /> 80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff .........0#.....<br /> 08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00 .0#.............<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x157/0x220<br /> [] kmalloc_trace+0x21/0x110<br /> [] watchdog_dev_register+0x4e/0x780 [watchdog]<br /> [] __watchdog_register_device+0x4f0/0x680 [watchdog]<br /> [] watchdog_register_device+0xd2/0x110 [watchdog]<br /> [] 0xffffffffc10880ae<br /> [] do_one_initcall+0xcb/0x4d0<br /> [] do_init_module+0x1ca/0x5f0<br /> [] load_module+0x6133/0x70f0<br /> ...<br /> <br /> unreferenced object 0xffff888105b9fa80 (size 16):<br /> comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s)<br /> hex dump (first 16 bytes):<br /> 77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff watchdog1.......<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x157/0x220<br /> [] __kmalloc_node_track_caller+0x44/0x1b0<br /> [] kvasprintf+0xb5/0x140<br /> [] kvasprintf_const+0x55/0x180<br /> [] kobject_set_name_vargs+0x56/0x150<br /> [] dev_set_name+0xab/0xe0<br /> [] watchdog_dev_register+0x285/0x780 [watchdog]<br /> [] __watchdog_register_device+0x4f0/0x680 [watchdog]<br /> [] watchdog_register_device+0xd2/0x110 [watchdog]<br /> [] 0xffffffffc10880ae<br /> [] do_one_initcall+0xcb/0x4d0<br /> [] do_init_module+0x1ca/0x5f0<br /> [] load_module+0x6133/0x70f0<br /> ...<br /> <br /> The reason is that put_device is not be called if cdev_device_add fails<br /> and wdd-&gt;id != 0.<br /> <br /> watchdog_cdev_register<br /> wd_data = kzalloc [1]<br /> err = dev_set_name [2]<br /> ..<br /> err = cdev_device_add<br /> if (err) {<br /> if (wdd-&gt;id == 0) { // wdd-&gt;id != 0<br /> ..<br /> }<br /> return err; // [1],[2] would be leaked<br /> <br /> To fix it, call put_device in all wdd-&gt;id cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/tests: helpers: Avoid a driver uaf<br /> <br /> when using __drm_kunit_helper_alloc_drm_device() the driver may be<br /> dereferenced by device-managed resources up until the device is<br /> freed, which is typically later than the kunit-managed resource code<br /> frees it. Fix this by simply make the driver device-managed as well.<br /> <br /> In short, the sequence leading to the UAF is as follows:<br /> <br /> INIT:<br /> Code allocates a struct device as a kunit-managed resource.<br /> Code allocates a drm driver as a kunit-managed resource.<br /> Code allocates a drm device as a device-managed resource.<br /> <br /> EXIT:<br /> Kunit resource cleanup frees the drm driver<br /> Kunit resource cleanup puts the struct device, which starts a<br /> device-managed resource cleanup<br /> device-managed cleanup calls drm_dev_put()<br /> drm_dev_put() dereferences the (now freed) drm driver -&gt; Boom.<br /> <br /> Related KASAN message:<br /> [55272.551542] ==================================================================<br /> [55272.551551] BUG: KASAN: slab-use-after-free in drm_dev_put.part.0+0xd4/0xe0 [drm]<br /> [55272.551603] Read of size 8 at addr ffff888127502828 by task kunit_try_catch/10353<br /> <br /> [55272.551612] CPU: 4 PID: 10353 Comm: kunit_try_catch Tainted: G U N 6.5.0-rc7+ #155<br /> [55272.551620] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021<br /> [55272.551626] Call Trace:<br /> [55272.551629] <br /> [55272.551633] dump_stack_lvl+0x57/0x90<br /> [55272.551639] print_report+0xcf/0x630<br /> [55272.551645] ? _raw_spin_lock_irqsave+0x5f/0x70<br /> [55272.551652] ? drm_dev_put.part.0+0xd4/0xe0 [drm]<br /> [55272.551694] kasan_report+0xd7/0x110<br /> [55272.551699] ? drm_dev_put.part.0+0xd4/0xe0 [drm]<br /> [55272.551742] drm_dev_put.part.0+0xd4/0xe0 [drm]<br /> [55272.551783] devres_release_all+0x15d/0x1f0<br /> [55272.551790] ? __pfx_devres_release_all+0x10/0x10<br /> [55272.551797] device_unbind_cleanup+0x16/0x1a0<br /> [55272.551802] device_release_driver_internal+0x3e5/0x540<br /> [55272.551808] ? kobject_put+0x5d/0x4b0<br /> [55272.551814] bus_remove_device+0x1f1/0x3f0<br /> [55272.551819] device_del+0x342/0x910<br /> [55272.551826] ? __pfx_device_del+0x10/0x10<br /> [55272.551830] ? lock_release+0x339/0x5e0<br /> [55272.551836] ? kunit_remove_resource+0x128/0x290 [kunit]<br /> [55272.551845] ? __pfx_lock_release+0x10/0x10<br /> [55272.551851] platform_device_del.part.0+0x1f/0x1e0<br /> [55272.551856] ? _raw_spin_unlock_irqrestore+0x30/0x60<br /> [55272.551863] kunit_remove_resource+0x195/0x290 [kunit]<br /> [55272.551871] ? _raw_spin_unlock_irqrestore+0x30/0x60<br /> [55272.551877] kunit_cleanup+0x78/0x120 [kunit]<br /> [55272.551885] ? __kthread_parkme+0xc1/0x1f0<br /> [55272.551891] ? __pfx_kunit_try_run_case_cleanup+0x10/0x10 [kunit]<br /> [55272.551900] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit]<br /> [55272.551909] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit]<br /> [55272.551919] kthread+0x2e7/0x3c0<br /> [55272.551924] ? __pfx_kthread+0x10/0x10<br /> [55272.551929] ret_from_fork+0x2d/0x70<br /> [55272.551935] ? __pfx_kthread+0x10/0x10<br /> [55272.551940] ret_from_fork_asm+0x1b/0x30<br /> [55272.551948] <br /> <br /> [55272.551953] Allocated by task 10351:<br /> [55272.551956] kasan_save_stack+0x1c/0x40<br /> [55272.551962] kasan_set_track+0x21/0x30<br /> [55272.551966] __kasan_kmalloc+0x8b/0x90<br /> [55272.551970] __kmalloc+0x5e/0x160<br /> [55272.551976] kunit_kmalloc_array+0x1c/0x50 [kunit]<br /> [55272.551984] drm_exec_test_init+0xfa/0x2c0 [drm_exec_test]<br /> [55272.551991] kunit_try_run_case+0xdd/0x250 [kunit]<br /> [55272.551999] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit]<br /> [55272.552008] kthread+0x2e7/0x3c0<br /> [55272.552012] ret_from_fork+0x2d/0x70<br /> [55272.552017] ret_from_fork_asm+0x1b/0x30<br /> <br /> [55272.552024] Freed by task 10353:<br /> [55272.552027] kasan_save_stack+0x1c/0x40<br /> [55272.552032] kasan_set_track+0x21/0x30<br /> [55272.552036] kasan_save_free_info+0x27/0x40<br /> [55272.552041] __kasan_slab_free+0x106/0x180<br /> [55272.552046] slab_free_freelist_hook+0xb3/0x160<br /> [55272.552051] __kmem_cache_free+0xb2/0x290<br /> [55272.552056] kunit_remove_resource+0x195/0x290 [kunit]<br /> [55272.552064] kunit_cleanup+0x7<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Do not corrupt the pfn list when doing batch carry<br /> <br /> If batch-&gt;end is 0 then setting npfns[0] before computing the new value of<br /> pfns will fail to adjust the pfn and result in various page accounting<br /> corruptions. It should be ordered after.<br /> <br /> This seems to result in various kinds of page meta-data corruption related<br /> failures:<br /> <br /> WARNING: CPU: 1 PID: 527 at mm/gup.c:75 try_grab_folio+0x503/0x740<br /> Modules linked in:<br /> CPU: 1 PID: 527 Comm: repro Not tainted 6.3.0-rc2-eeac8ede1755+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:try_grab_folio+0x503/0x740<br /> Code: e3 01 48 89 de e8 6d c1 dd ff 48 85 db 0f 84 7c fe ff ff e8 4f bf dd ff 49 8d 47 ff 48 89 45 d0 e9 73 fe ff ff e8 3d bf dd ff 0b 31 db e9 d0 fc ff ff e8 2f bf dd ff 48 8b 5d c8 31 ff 48 89<br /> RSP: 0018:ffffc90000f37908 EFLAGS: 00010046<br /> RAX: 0000000000000000 RBX: 00000000fffffc02 RCX: ffffffff81504c26<br /> RDX: 0000000000000000 RSI: ffff88800d030000 RDI: 0000000000000002<br /> RBP: ffffc90000f37948 R08: 000000000003ca24 R09: 0000000000000008<br /> R10: 000000000003ca00 R11: 0000000000000023 R12: ffffea000035d540<br /> R13: 0000000000000001 R14: 0000000000000000 R15: ffffea000035d540<br /> FS: 00007fecbf659740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000200011c3 CR3: 000000000ef66006 CR4: 0000000000770ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> internal_get_user_pages_fast+0xd32/0x2200<br /> pin_user_pages_fast+0x65/0x90<br /> pfn_reader_user_pin+0x376/0x390<br /> pfn_reader_next+0x14a/0x7b0<br /> pfn_reader_first+0x140/0x1b0<br /> iopt_area_fill_domain+0x74/0x210<br /> iopt_table_add_domain+0x30e/0x6e0<br /> iommufd_device_selftest_attach+0x7f/0x140<br /> iommufd_test+0x10ff/0x16f0<br /> iommufd_fops_ioctl+0x206/0x330<br /> __x64_sys_ioctl+0x10e/0x160<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v11_0_hw_fini<br /> <br /> The gmc.ecc_irq is enabled by firmware per IFWI setting,<br /> and the host driver is not privileged to enable/disable<br /> the interrupt. So, it is meaningless to use the amdgpu_irq_put<br /> function in gmc_v11_0_hw_fini, which also leads to the call<br /> trace.<br /> <br /> [ 102.980303] Call Trace:<br /> [ 102.980303] <br /> [ 102.980304] gmc_v11_0_hw_fini+0x54/0x90 [amdgpu]<br /> [ 102.980357] gmc_v11_0_suspend+0xe/0x20 [amdgpu]<br /> [ 102.980409] amdgpu_device_ip_suspend_phase2+0x240/0x460 [amdgpu]<br /> [ 102.980459] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]<br /> [ 102.980520] amdgpu_device_pre_asic_reset+0xd9/0x490 [amdgpu]<br /> [ 102.980573] amdgpu_device_gpu_recover.cold+0x548/0xce6 [amdgpu]<br /> [ 102.980687] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]<br /> [ 102.980740] process_one_work+0x21f/0x3f0<br /> [ 102.980741] worker_thread+0x200/0x3e0<br /> [ 102.980742] ? process_one_work+0x3f0/0x3f0<br /> [ 102.980743] kthread+0xfd/0x130<br /> [ 102.980743] ? kthread_complete_and_exit+0x20/0x20<br /> [ 102.980744] ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: hisilicon: Fix an out of bounds check in hisi_inno_phy_probe()<br /> <br /> The size of array &amp;#39;priv-&gt;ports[]&amp;#39; is INNO_PHY_PORT_NUM.<br /> <br /> In the for loop, &amp;#39;i&amp;#39; is used as the index for array &amp;#39;priv-&gt;ports[]&amp;#39;<br /> with a check (i &gt; INNO_PHY_PORT_NUM) which indicates that<br /> INNO_PHY_PORT_NUM is allowed value for &amp;#39;i&amp;#39; in the same loop.<br /> <br /> This &gt; comparison needs to be changed to &gt;=, otherwise it potentially leads<br /> to an out of bounds write on the next iteration through the loop

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dsi: Add missing check for alloc_ordered_workqueue<br /> <br /> Add check for the return value of alloc_ordered_workqueue as it may return<br /> NULL pointer and cause NULL pointer dereference.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/517646/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: Fix function prototype mismatch for ext4_feat_ktype<br /> <br /> With clang&amp;#39;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),<br /> indirect call targets are validated against the expected function<br /> pointer prototype to make sure the call target is valid to help mitigate<br /> ROP attacks. If they are not identical, there is a failure at run time,<br /> which manifests as either a kernel panic or thread getting killed.<br /> <br /> ext4_feat_ktype was setting the "release" handler to "kfree", which<br /> doesn&amp;#39;t have a matching function prototype. Add a simple wrapper<br /> with the correct prototype.<br /> <br /> This was found as a result of Clang&amp;#39;s new -Wcast-function-type-strict<br /> flag, which is more sensitive than the simpler -Wcast-function-type,<br /> which only checks for type width mismatches.<br /> <br /> Note that this code is only reached when ext4 is a loadable module and<br /> it is being unloaded:<br /> <br /> CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698)<br /> ...<br /> RIP: 0010:kobject_put+0xbb/0x1b0<br /> ...<br /> Call Trace:<br /> <br /> ext4_exit_sysfs+0x14/0x60 [ext4]<br /> cleanup_module+0x67/0xedb [ext4]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: imx: Don&amp;#39;t skip cleanup in remove&amp;#39;s error path<br /> <br /> Returning early in a platform driver&amp;#39;s remove callback is wrong. In this<br /> case the dma resources are not released in the error path. this is never<br /> retried later and so this is a permanent leak. To fix this, only skip<br /> hardware disabling if waking the device fails.