Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()<br /> <br /> In Google internal bug 265639009 we&amp;#39;ve received an (as yet) unreproducible<br /> crash report from an aarch64 GKI 5.10.149-android13 running device.<br /> <br /> AFAICT the source code is at:<br /> https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10<br /> <br /> The call stack is:<br /> ncm_close() -&gt; ncm_notify() -&gt; ncm_do_notify()<br /> with the crash at:<br /> ncm_do_notify+0x98/0x270<br /> Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)<br /> <br /> Which I believe disassembles to (I don&amp;#39;t know ARM assembly, but it looks sane enough to me...):<br /> <br /> // halfword (16-bit) store presumably to event-&gt;wLength (at offset 6 of struct usb_cdc_notification)<br /> 0B 0D 00 79 strh w11, [x8, #6]<br /> <br /> // word (32-bit) store presumably to req-&gt;Length (at offset 8 of struct usb_request)<br /> 6C 0A 00 B9 str w12, [x19, #8]<br /> <br /> // x10 (NULL) was read here from offset 0 of valid pointer x9<br /> // IMHO we&amp;#39;re reading &amp;#39;cdev-&gt;gadget&amp;#39; and getting NULL<br /> // gadget is indeed at offset 0 of struct usb_composite_dev<br /> 2A 01 40 F9 ldr x10, [x9]<br /> <br /> // loading req-&gt;buf pointer, which is at offset 0 of struct usb_request<br /> 69 02 40 F9 ldr x9, [x19]<br /> <br /> // x10 is null, crash, appears to be attempt to read cdev-&gt;gadget-&gt;max_speed<br /> 4B 5D 40 B9 ldr w11, [x10, #0x5c]<br /> <br /> which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:<br /> <br /> event-&gt;wLength = cpu_to_le16(8);<br /> req-&gt;length = NCM_STATUS_BYTECOUNT;<br /> <br /> /* SPEED_CHANGE data is up/down speeds in bits/sec */<br /> data = req-&gt;buf + sizeof *event;<br /> data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));<br /> <br /> My analysis of registers and NULL ptr deref crash offset<br /> (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)<br /> heavily suggests that the crash is due to &amp;#39;cdev-&gt;gadget&amp;#39; being NULL when executing:<br /> data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));<br /> which calls:<br /> ncm_bitrate(NULL)<br /> which then calls:<br /> gadget_is_superspeed(NULL)<br /> which reads<br /> ((struct usb_gadget *)NULL)-&gt;max_speed<br /> and hits a panic.<br /> <br /> AFAICT, if I&amp;#39;m counting right, the offset of max_speed is indeed 0x5C.<br /> (remember there&amp;#39;s a GKI KABI reservation of 16 bytes in struct work_struct)<br /> <br /> It&amp;#39;s not at all clear to me how this is all supposed to work...<br /> but returning 0 seems much better than panic-ing...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: Cleanup partial engine discovery failures<br /> <br /> If we abort driver initialisation in the middle of gt/engine discovery,<br /> some engines will be fully setup and some not. Those incompletely setup<br /> engines only have &amp;#39;engine-&gt;release == NULL&amp;#39; and so will leak any of the<br /> common objects allocated.<br /> <br /> v2:<br /> - Drop the destroy_pinned_context() helper for now. It&amp;#39;s not really<br /> worth it with just a single callsite at the moment. (Janusz)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Let probe fail when workqueue cannot be enabled<br /> <br /> The workqueue is enabled when the appropriate driver is loaded and<br /> disabled when the driver is removed. When the driver is removed it<br /> assumes that the workqueue was enabled successfully and proceeds to<br /> free allocations made during workqueue enabling.<br /> <br /> Failure during workqueue enabling does not prevent the driver from<br /> being loaded. This is because the error path within drv_enable_wq()<br /> returns success unless a second failure is encountered<br /> during the error path. By returning success it is possible to load<br /> the driver even if the workqueue cannot be enabled and<br /> allocations that do not exist are attempted to be freed during<br /> driver remove.<br /> <br /> Some examples of problematic flows:<br /> (a)<br /> <br /> idxd_dmaengine_drv_probe() -&gt; drv_enable_wq() -&gt; idxd_wq_request_irq():<br /> In above flow, if idxd_wq_request_irq() fails then<br /> idxd_wq_unmap_portal() is called on error exit path, but<br /> drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The<br /> driver is thus loaded successfully.<br /> <br /> idxd_dmaengine_drv_remove()-&gt;drv_disable_wq()-&gt;idxd_wq_unmap_portal()<br /> Above flow on driver unload triggers the WARN in devm_iounmap() because<br /> the device resource has already been removed during error path of<br /> drv_enable_wq().<br /> <br /> (b)<br /> <br /> idxd_dmaengine_drv_probe() -&gt; drv_enable_wq() -&gt; idxd_wq_request_irq():<br /> In above flow, if idxd_wq_request_irq() fails then<br /> idxd_wq_init_percpu_ref() is never called to initialize the percpu<br /> counter, yet the driver loads successfully because drv_enable_wq()<br /> returns 0.<br /> <br /> idxd_dmaengine_drv_remove()-&gt;__idxd_wq_quiesce()-&gt;percpu_ref_kill():<br /> Above flow on driver unload triggers a BUG when attempting to drop the<br /> initial ref of the uninitialized percpu ref:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> <br /> Fix the drv_enable_wq() error path by returning the original error that<br /> indicates failure of workqueue enabling. This ensures that the probe<br /> fails when an error is encountered and the driver remove paths are only<br /> attempted when the workqueue was enabled successfully.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadgetfs: Fix race between mounting and unmounting<br /> <br /> The syzbot fuzzer and Gerald Lee have identified a use-after-free bug<br /> in the gadgetfs driver, involving processes concurrently mounting and<br /> unmounting the gadgetfs filesystem. In particular, gadgetfs_fill_super()<br /> can race with gadgetfs_kill_sb(), causing the latter to deallocate<br /> the_device while the former is using it. The output from KASAN says,<br /> in part:<br /> <br /> BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]<br /> BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]<br /> BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]<br /> BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]<br /> BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]<br /> BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]<br /> BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086<br /> Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689<br /> <br /> CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Call Trace:<br /> <br /> ...<br /> atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]<br /> __refcount_sub_and_test include/linux/refcount.h:272 [inline]<br /> __refcount_dec_and_test include/linux/refcount.h:315 [inline]<br /> refcount_dec_and_test include/linux/refcount.h:333 [inline]<br /> put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]<br /> gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086<br /> deactivate_locked_super+0xa7/0xf0 fs/super.c:332<br /> vfs_get_super fs/super.c:1190 [inline]<br /> get_tree_single+0xd0/0x160 fs/super.c:1207<br /> vfs_get_tree+0x88/0x270 fs/super.c:1531<br /> vfs_fsconfig_locked fs/fsopen.c:232 [inline]<br /> <br /> The simplest solution is to ensure that gadgetfs_fill_super() and<br /> gadgetfs_kill_sb() are serialized by making them both acquire a new<br /> mutex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: fix possible null-ptr-defer in spk_ttyio_release<br /> <br /> Run the following tests on the qemu platform:<br /> <br /> syzkaller:~# modprobe speakup_audptr<br /> input: Speakup as /devices/virtual/input/input4<br /> initialized device: /dev/synth, node (MAJOR 10, MINOR 125)<br /> speakup 3.1.6: initialized<br /> synth name on entry is: (null)<br /> synth probe<br /> <br /> spk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned<br /> failed (errno -16), then remove the module, we will get a null-ptr-defer<br /> problem, as follow:<br /> <br /> syzkaller:~# modprobe -r speakup_audptr<br /> releasing synth audptr<br /> BUG: kernel NULL pointer dereference, address: 0000000000000080<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0002 [#1] PREEMPT SMP PTI<br /> CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1<br /> RIP: 0010:mutex_lock+0x14/0x30<br /> Call Trace:<br /> <br /> spk_ttyio_release+0x19/0x70 [speakup]<br /> synth_release.part.6+0xac/0xc0 [speakup]<br /> synth_remove+0x56/0x60 [speakup]<br /> __x64_sys_delete_module+0x156/0x250<br /> ? fpregs_assert_state_consistent+0x1d/0x50<br /> do_syscall_64+0x37/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Modules linked in: speakup_audptr(-) speakup<br /> Dumping ftrace buffer:<br /> <br /> in_synth-&gt;dev was not initialized during modprobe, so we add check<br /> for in_synth-&gt;dev to fix this bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer<br /> <br /> Driver&amp;#39;s probe allocates memory for RX FIFO (port-&gt;rx_fifo) based on<br /> default RX FIFO depth, e.g. 16. Later during serial startup the<br /> qcom_geni_serial_port_setup() updates the RX FIFO depth<br /> (port-&gt;rx_fifo_depth) to match real device capabilities, e.g. to 32.<br /> <br /> The RX UART handle code will read "port-&gt;rx_fifo_depth" number of words<br /> into "port-&gt;rx_fifo" buffer, thus exceeding the bounds. This can be<br /> observed in certain configurations with Qualcomm Bluetooth HCI UART<br /> device and KASAN:<br /> <br /> Bluetooth: hci0: QCA Product ID :0x00000010<br /> Bluetooth: hci0: QCA SOC Version :0x400a0200<br /> Bluetooth: hci0: QCA ROM Version :0x00000200<br /> Bluetooth: hci0: QCA Patch Version:0x00000d2b<br /> Bluetooth: hci0: QCA controller version 0x02000200<br /> Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv<br /> bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2<br /> Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2)<br /> Bluetooth: hci0: QCA Failed to download patch (-2)<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c<br /> Write of size 4 at addr ffff279347d578c0 by task swapper/0/0<br /> <br /> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26<br /> Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)<br /> Call trace:<br /> dump_backtrace.part.0+0xe0/0xf0<br /> show_stack+0x18/0x40<br /> dump_stack_lvl+0x8c/0xb8<br /> print_report+0x188/0x488<br /> kasan_report+0xb4/0x100<br /> __asan_store4+0x80/0xa4<br /> handle_rx_uart+0xa8/0x18c<br /> qcom_geni_serial_handle_rx+0x84/0x9c<br /> qcom_geni_serial_isr+0x24c/0x760<br /> __handle_irq_event_percpu+0x108/0x500<br /> handle_irq_event+0x6c/0x110<br /> handle_fasteoi_irq+0x138/0x2cc<br /> generic_handle_domain_irq+0x48/0x64<br /> <br /> If the RX FIFO depth changes after probe, be sure to resize the buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix use-after-free race condition for maps<br /> <br /> It is possible that in between calling fastrpc_map_get() until<br /> map-&gt;fl-&gt;lock is taken in fastrpc_free_map(), another thread can call<br /> fastrpc_map_lookup() and get a reference to a map that is about to be<br /> deleted.<br /> <br /> Rewrite fastrpc_map_get() to only increase the reference count of a map<br /> if it&amp;#39;s non-zero. Propagate this to callers so they can know if a map is<br /> about to be deleted.<br /> <br /> Fixes this warning:<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate<br /> ...<br /> Call trace:<br /> refcount_warn_saturate<br /> [fastrpc_map_get inlined]<br /> [fastrpc_map_lookup inlined]<br /> fastrpc_map_create<br /> fastrpc_internal_invoke<br /> fastrpc_device_ioctl<br /> __arm64_sys_ioctl<br /> invoke_syscall

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Don&amp;#39;t remove map on creater_process and device_release<br /> <br /> Do not remove the map from the list on error path in<br /> fastrpc_init_create_process, instead call fastrpc_map_put, to avoid<br /> use-after-free. Do not remove it on fastrpc_device_release either,<br /> call fastrpc_map_put instead.<br /> <br /> The fastrpc_free_map is the only proper place to remove the map.<br /> This is called only after the reference count is 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix use-after-free and race in fastrpc_map_find<br /> <br /> Currently, there is a race window between the point when the mutex is<br /> unlocked in fastrpc_map_lookup and the reference count increasing<br /> (fastrpc_map_get) in fastrpc_map_find, which can also lead to<br /> use-after-free.<br /> <br /> So lets merge fastrpc_map_find into fastrpc_map_lookup which allows us<br /> to both protect the maps list by also taking the &amp;fl-&gt;lock spinlock and<br /> the reference count, since the spinlock will be released only after.<br /> Add take_ref argument to make this suitable for all callers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: sdata can be NULL during AMPDU start<br /> <br /> ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a<br /> deauthentication is ongoing.<br /> <br /> Here a trace triggering the race with the hostapd test<br /> multi_ap_fronthaul_on_ap:<br /> <br /> (gdb) list *drv_ampdu_action+0x46<br /> 0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).<br /> 391 int ret = -EOPNOTSUPP;<br /> 392<br /> 393 might_sleep();<br /> 394<br /> 395 sdata = get_bss_sdata(sdata);<br /> 396 if (!check_sdata_in_driver(sdata))<br /> 397 return -EIO;<br /> 398<br /> 399 trace_drv_ampdu_action(local, sdata, params);<br /> 400<br /> <br /> wlan0: moving STA 02:00:00:00:03:00 to state 3<br /> wlan0: associated<br /> wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)<br /> wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0<br /> wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)<br /> wlan0: moving STA 02:00:00:00:03:00 to state 2<br /> wlan0: moving STA 02:00:00:00:03:00 to state 1<br /> wlan0: Removed STA 02:00:00:00:03:00<br /> wlan0: Destroyed STA 02:00:00:00:03:00<br /> BUG: unable to handle page fault for address: fffffffffffffb48<br /> PGD 11814067 P4D 11814067 PUD 11816067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014<br /> Workqueue: phy3 ieee80211_ba_session_work [mac80211]<br /> RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]<br /> Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85<br /> RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287<br /> RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240<br /> RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40<br /> RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001<br /> R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0<br /> R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8<br /> FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0<br /> Call Trace:<br /> <br /> ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211]<br /> ieee80211_ba_session_work+0xff/0x2e0 [mac80211]<br /> process_one_work+0x29f/0x620<br /> worker_thread+0x4d/0x3d0<br /> ? process_one_work+0x620/0x620<br /> kthread+0xfb/0x120<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix initialization of rx-&gt;link and rx-&gt;link_sta<br /> <br /> There are some codepaths that do not initialize rx-&gt;link_sta properly. This<br /> causes a crash in places which assume that rx-&gt;link_sta is valid if rx-&gt;sta<br /> is valid.<br /> One known instance is triggered by __ieee80211_rx_h_amsdu being called from<br /> fast-rx. It results in a crash like this one:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000a8<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page PGD 0 P4D 0<br /> Oops: 0002 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 506 Comm: mt76-usb-rx phy Tainted: G E 6.1.0-debian64x+1.7 #3<br /> Hardware name: ZOTAC ZBOX-ID92/ZBOX-IQ01/ZBOX-ID92/ZBOX-IQ01, BIOS B220P007 05/21/2014<br /> RIP: 0010:ieee80211_deliver_skb+0x62/0x1f0 [mac80211]<br /> Code: 00 48 89 04 24 e8 9e a7 c3 df 89 c0 48 03 1c c5 a0 ea 39 a1 4c 01 6b 08 48 ff 03 48<br /> 83 7d 28 00 74 11 48 8b 45 30 48 63 55 44 83 84 d0 a8 00 00 00 01 41 8b 86 c0<br /> 11 00 00 8d 50 fd 83 fa 01<br /> RSP: 0018:ffff999040803b10 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffffb9903f496480 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffff999040803ce0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d21828ac900<br /> R13: 000000000000004a R14: ffff8d2198ed89c0 R15: ffff8d2198ed8000<br /> FS: 0000000000000000(0000) GS:ffff8d24afe80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000000a8 CR3: 0000000429810002 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> __ieee80211_rx_h_amsdu+0x1b5/0x240 [mac80211]<br /> ? ieee80211_prepare_and_rx_handle+0xcdd/0x1320 [mac80211]<br /> ? __local_bh_enable_ip+0x3b/0xa0<br /> ieee80211_prepare_and_rx_handle+0xcdd/0x1320 [mac80211]<br /> ? prepare_transfer+0x109/0x1a0 [xhci_hcd]<br /> ieee80211_rx_list+0xa80/0xda0 [mac80211]<br /> mt76_rx_complete+0x207/0x2e0 [mt76]<br /> mt76_rx_poll_complete+0x357/0x5a0 [mt76]<br /> mt76u_rx_worker+0x4f5/0x600 [mt76_usb]<br /> ? mt76_get_min_avg_rssi+0x140/0x140 [mt76]<br /> __mt76_worker_fn+0x50/0x80 [mt76]<br /> kthread+0xed/0x120<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br /> <br /> Since the initialization of rx-&gt;link and rx-&gt;link_sta is rather convoluted<br /> and duplicated in many places, clean it up by using a helper function to<br /> set it.<br /> <br /> [remove unnecessary rx-&gt;sta-&gt;sta.mlo check]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: let&amp;#39;s avoid panic if extent_tree is not created<br /> <br /> This patch avoids the below panic.<br /> <br /> pc : __lookup_extent_tree+0xd8/0x760<br /> lr : f2fs_do_write_data_page+0x104/0x87c<br /> sp : ffffffc010cbb3c0<br /> x29: ffffffc010cbb3e0 x28: 0000000000000000<br /> x27: ffffff8803e7f020 x26: ffffff8803e7ed40<br /> x25: ffffff8803e7f020 x24: ffffffc010cbb460<br /> x23: ffffffc010cbb480 x22: 0000000000000000<br /> x21: 0000000000000000 x20: ffffffff22e90900<br /> x19: 0000000000000000 x18: ffffffc010c5d080<br /> x17: 0000000000000000 x16: 0000000000000020<br /> x15: ffffffdb1acdbb88 x14: ffffff888759e2b0<br /> x13: 0000000000000000 x12: ffffff802da49000<br /> x11: 000000000a001200 x10: ffffff8803e7ed40<br /> x9 : ffffff8023195800 x8 : ffffff802da49078<br /> x7 : 0000000000000001 x6 : 0000000000000000<br /> x5 : 0000000000000006 x4 : ffffffc010cbba28<br /> x3 : 0000000000000000 x2 : ffffffc010cbb480<br /> x1 : 0000000000000000 x0 : ffffff8803e7ed40<br /> Call trace:<br /> __lookup_extent_tree+0xd8/0x760<br /> f2fs_do_write_data_page+0x104/0x87c<br /> f2fs_write_single_data_page+0x420/0xb60<br /> f2fs_write_cache_pages+0x418/0xb1c<br /> __f2fs_write_data_pages+0x428/0x58c<br /> f2fs_write_data_pages+0x30/0x40<br /> do_writepages+0x88/0x190<br /> __writeback_single_inode+0x48/0x448<br /> writeback_sb_inodes+0x468/0x9e8<br /> __writeback_inodes_wb+0xb8/0x2a4<br /> wb_writeback+0x33c/0x740<br /> wb_do_writeback+0x2b4/0x400<br /> wb_workfn+0xe4/0x34c<br /> process_one_work+0x24c/0x5bc<br /> worker_thread+0x3e8/0xa50<br /> kthread+0x150/0x1b4