Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal/drivers/hisi: Drop second sensor hi3660<br /> <br /> The commit 74c8e6bffbe1 ("driver core: Add __alloc_size hint to devm<br /> allocators") exposes a panic "BRK handler: Fatal exception" on the<br /> hi3660_thermal_probe funciton.<br /> This is because the function allocates memory for only one<br /> sensors array entry, but tries to fill up a second one.<br /> <br /> Fix this by removing the unneeded second access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: add handling for RAID1C23/DUP to btrfs_reduce_alloc_profile<br /> <br /> Callers of `btrfs_reduce_alloc_profile` expect it to return exactly<br /> one allocation profile flag, and failing to do so may ultimately<br /> result in a WARN_ON and remount-ro when allocating new blocks, like<br /> the below transaction abort on 6.1.<br /> <br /> `btrfs_reduce_alloc_profile` has two ways of determining the profile,<br /> first it checks if a conversion balance is currently running and<br /> uses the profile we&amp;#39;re converting to. If no balance is currently<br /> running, it returns the max-redundancy profile which at least one<br /> block in the selected block group has.<br /> <br /> This works by simply checking each known allocation profile bit in<br /> redundancy order. However, `btrfs_reduce_alloc_profile` has not been<br /> updated as new flags have been added - first with the `DUP` profile<br /> and later with the RAID1C34 profiles.<br /> <br /> Because of the way it checks, if we have blocks with different<br /> profiles and at least one is known, that profile will be selected.<br /> However, if none are known we may return a flag set with multiple<br /> allocation profiles set.<br /> <br /> This is currently only possible when a balance from one of the three<br /> unhandled profiles to another of the unhandled profiles is canceled<br /> after allocating at least one block using the new profile.<br /> <br /> In that case, a transaction abort like the below will occur and the<br /> filesystem will need to be mounted with -o skip_balance to get it<br /> mounted rw again (but the balance cannot be resumed without a<br /> similar abort).<br /> <br /> [770.648] ------------[ cut here ]------------<br /> [770.648] BTRFS: Transaction aborted (error -22)<br /> [770.648] WARNING: CPU: 43 PID: 1159593 at fs/btrfs/extent-tree.c:4122 find_free_extent+0x1d94/0x1e00 [btrfs]<br /> [770.648] CPU: 43 PID: 1159593 Comm: btrfs Tainted: G W 6.1.0-0.deb11.7-powerpc64le #1 Debian 6.1.20-2~bpo11+1a~test<br /> [770.648] Hardware name: T2P9D01 REV 1.00 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV<br /> [770.648] NIP: c00800000f6784fc LR: c00800000f6784f8 CTR: c000000000d746c0<br /> [770.648] REGS: c000200089afe9a0 TRAP: 0700 Tainted: G W (6.1.0-0.deb11.7-powerpc64le Debian 6.1.20-2~bpo11+1a~test)<br /> [770.648] MSR: 9000000002029033 CR: 28848282 XER: 20040000<br /> [770.648] CFAR: c000000000135110 IRQMASK: 0<br /> GPR00: c00800000f6784f8 c000200089afec40 c00800000f7ea800 0000000000000026<br /> GPR04: 00000001004820c2 c000200089afea00 c000200089afe9f8 0000000000000027<br /> GPR08: c000200ffbfe7f98 c000000002127f90 ffffffffffffffd8 0000000026d6a6e8<br /> GPR12: 0000000028848282 c000200fff7f3800 5deadbeef0000122 c00000002269d000<br /> GPR16: c0002008c7797c40 c000200089afef17 0000000000000000 0000000000000000<br /> GPR20: 0000000000000000 0000000000000001 c000200008bc5a98 0000000000000001<br /> GPR24: 0000000000000000 c0000003c73088d0 c000200089afef17 c000000016d3a800<br /> GPR28: c0000003c7308800 c00000002269d000 ffffffffffffffea 0000000000000001<br /> [770.648] NIP [c00800000f6784fc] find_free_extent+0x1d94/0x1e00 [btrfs]<br /> [770.648] LR [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs]<br /> [770.648] Call Trace:<br /> [770.648] [c000200089afec40] [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] (unreliable)<br /> [770.648] [c000200089afed30] [c00800000f681398] btrfs_reserve_extent+0x1a0/0x2f0 [btrfs]<br /> [770.648] [c000200089afeea0] [c00800000f681bf0] btrfs_alloc_tree_block+0x108/0x670 [btrfs]<br /> [770.648] [c000200089afeff0] [c00800000f66bd68] __btrfs_cow_block+0x170/0x850 [btrfs]<br /> [770.648] [c000200089aff100] [c00800000f66c58c] btrfs_cow_block+0x144/0x288 [btrfs]<br /> [770.648] [c000200089aff1b0] [c00800000f67113c] btrfs_search_slot+0x6b4/0xcb0 [btrfs]<br /> [770.648] [c000200089aff2a0] [c00800000f679f60] lookup_inline_extent_backref+0x128/0x7c0 [btrfs]<br /> [770.648] [c000200089aff3b0] [c00800000f67b338] lookup_extent_backref+0x70/0x190 [btrfs]<br /> [770.648] [c000200089aff470] [c00800000f67b54c] __btrfs_free_extent+0xf4/0x1490 [btrfs]<br /> [770.648] [<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pci: tw68: Fix null-ptr-deref bug in buf prepare and finish<br /> <br /> When the driver calls tw68_risc_buffer() to prepare the buffer, the<br /> function call dma_alloc_coherent may fail, resulting in a empty buffer<br /> buf-&gt;cpu. Later when we free the buffer or access the buffer, null ptr<br /> deref is triggered.<br /> <br /> This bug is similar to the following one:<br /> https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71.<br /> <br /> We believe the bug can be also dynamically triggered from user side.<br /> Similarly, we fix this by checking the return value of tw68_risc_buffer()<br /> and the value of buf-&gt;cpu before buffer free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: storvsc: Fix handling of virtual Fibre Channel timeouts<br /> <br /> Hyper-V provides the ability to connect Fibre Channel LUNs to the host<br /> system and present them in a guest VM as a SCSI device. I/O to the vFC<br /> device is handled by the storvsc driver. The storvsc driver includes a<br /> partial integration with the FC transport implemented in the generic<br /> portion of the Linux SCSI subsystem so that FC attributes can be displayed<br /> in /sys. However, the partial integration means that some aspects of vFC<br /> don&amp;#39;t work properly. Unfortunately, a full and correct integration isn&amp;#39;t<br /> practical because of limitations in what Hyper-V provides to the guest.<br /> <br /> In particular, in the context of Hyper-V storvsc, the FC transport timeout<br /> function fc_eh_timed_out() causes a kernel panic because it can&amp;#39;t find the<br /> rport and dereferences a NULL pointer. The original patch that added the<br /> call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this<br /> regard.<br /> <br /> In many cases a timeout is due to a transient condition, so the situation<br /> can be improved by just continuing to wait like with other I/O requests<br /> issued by storvsc, and avoiding the guaranteed panic. For a permanent<br /> failure, continuing to wait may result in a hung thread instead of a panic,<br /> which again may be better.<br /> <br /> So fix the panic by removing the storvsc call to fc_eh_timed_out(). This<br /> allows storvsc to keep waiting for a response. The change has been tested<br /> by users who experienced a panic in fc_eh_timed_out() due to transient<br /> timeouts, and it solves their problem.<br /> <br /> In the future we may want to deprecate the vFC functionality in storvsc<br /> since it can&amp;#39;t be fully fixed. But it has current users for whom it is<br /> working well enough, so it should probably stay for a while longer.

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 /> 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