Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: qcom: at803x: fix kernel panic with at8031_probe<br /> <br /> On reworking and splitting the at803x driver, in splitting function of<br /> at803x PHYs it was added a NULL dereference bug where priv is referenced<br /> before it&amp;#39;s actually allocated and then is tried to write to for the<br /> is_1000basex and is_fiber variables in the case of at8031, writing on<br /> the wrong address.<br /> <br /> Fix this by correctly setting priv local variable only after<br /> at803x_probe is called and actually allocates priv in the phydev struct.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nouveau/dmem: handle kcalloc() allocation failure<br /> <br /> The kcalloc() in nouveau_dmem_evict_chunk() will return null if<br /> the physical memory has run out. As a result, if we dereference<br /> src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs<br /> will happen.<br /> <br /> Moreover, the GPU is going away. If the kcalloc() fails, we could not<br /> evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL<br /> flag in kcalloc().<br /> <br /> Finally, as there is no need to have physically contiguous memory,<br /> this patch switches kcalloc() to kvcalloc() in order to avoid<br /> failing allocations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode()<br /> <br /> If we have no VBT, or the VBT didn&amp;#39;t declare the encoder<br /> in question, we won&amp;#39;t have the &amp;#39;devdata&amp;#39; for the encoder.<br /> Instead of oopsing just bail early.<br /> <br /> We won&amp;#39;t be able to tell whether the port is DP++ or not,<br /> but so be it.<br /> <br /> (cherry picked from commit 26410896206342c8a80d2b027923e9ee7d33b733)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Fix deadlock in usb_deauthorize_interface()<br /> <br /> Among the attribute file callback routines in<br /> drivers/usb/core/sysfs.c, the interface_authorized_store() function is<br /> the only one which acquires a device lock on an ancestor device: It<br /> calls usb_deauthorize_interface(), which locks the interface&amp;#39;s parent<br /> USB device.<br /> <br /> The will lead to deadlock if another process already owns that lock<br /> and tries to remove the interface, whether through a configuration<br /> change or because the device has been disconnected. As part of the<br /> removal procedure, device_del() waits for all ongoing sysfs attribute<br /> callbacks to complete. But usb_deauthorize_interface() can&amp;#39;t complete<br /> until the device lock has been released, and the lock won&amp;#39;t be<br /> released until the removal has finished.<br /> <br /> The mechanism provided by sysfs to prevent this kind of deadlock is<br /> to use the sysfs_break_active_protection() function, which tells sysfs<br /> not to wait for the attribute callback.<br /> <br /> Reported-and-tested by: Yue Sun <br /> Reported by: xingwei lee

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: validate request buffer size in smb2_allocate_rsp_buf()<br /> <br /> The response buffer should be allocated in smb2_allocate_rsp_buf<br /> before validating request. But the fields in payload as well as smb2 header<br /> is used in smb2_allocate_rsp_buf(). This patch add simple buffer size<br /> validation to avoid potencial out-of-bounds in request buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Fix unremoved procfs host directory regression<br /> <br /> Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name}<br /> directory earlier") fixed a bug related to modules loading/unloading, by<br /> adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led<br /> to a potential duplicate call to the hostdir_rm() routine, since it&amp;#39;s also<br /> called from scsi_host_dev_release(). That triggered a regression report,<br /> which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host<br /> directory removal regression"). The fix just dropped the hostdir_rm() call<br /> from dev_release().<br /> <br /> But it happens that this proc directory is created on scsi_host_alloc(),<br /> and that function "pairs" with scsi_host_dev_release(), while<br /> scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the<br /> reason for removing the proc directory on dev_release() was meant to cover<br /> cases in which a SCSI host structure was allocated, but the call to<br /> scsi_add_host() didn&amp;#39;t happen. And that pattern happens to exist in some<br /> error paths, for example.<br /> <br /> Syzkaller causes that by using USB raw gadget device, error&amp;#39;ing on<br /> usb-storage driver, at usb_stor_probe2(). By checking that path, we can see<br /> that the BadDevice label leads to a scsi_host_put() after a SCSI host<br /> allocation, but there&amp;#39;s no call to scsi_add_host() in such path. That leads<br /> to messages like this in dmesg (and a leak of the SCSI host proc<br /> structure):<br /> <br /> usb-storage 4-1:87.51: USB Mass Storage device detected<br /> proc_dir_entry &amp;#39;scsi/usb-storage&amp;#39; already registered<br /> WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376<br /> <br /> The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),<br /> but guard that with the state check for SHOST_CREATED; there is even a<br /> comment in scsi_host_dev_release() detailing that: such conditional is<br /> meant for cases where the SCSI host was allocated but there was no calls to<br /> {add,remove}_host(), like the usb-storage case.<br /> <br /> This is what we propose here and with that, the error path of usb-storage<br /> does not trigger the warning anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: Reset queue_priority_hint on parking<br /> <br /> Originally, with strict in order execution, we could complete execution<br /> only when the queue was empty. Preempt-to-busy allows replacement of an<br /> active request that may complete before the preemption is processed by<br /> HW. If that happens, the request is retired from the queue, but the<br /> queue_priority_hint remains set, preventing direct submission until<br /> after the next CS interrupt is processed.<br /> <br /> This preempt-to-busy race can be triggered by the heartbeat, which will<br /> also act as the power-management barrier and upon completion allow us to<br /> idle the HW. We may process the completion of the heartbeat, and begin<br /> parking the engine before the CS event that restores the<br /> queue_priority_hint, causing us to fail the assertion that it is MIN.<br /> <br /> [ 166.210729] __engine_park:283 GEM_BUG_ON(engine-&gt;sched_engine-&gt;queue_priority_hint != (-((int)(~0U &gt;&gt; 1)) - 1))<br /> [ 166.210781] Dumping ftrace buffer:<br /> [ 166.210795] ---------------------------------<br /> ...<br /> [ 167.302811] drm_fdin-1097 2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }<br /> [ 167.302861] drm_fdin-1097 2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646<br /> [ 167.302928] drm_fdin-1097 2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0<br /> [ 167.302992] drm_fdin-1097 2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659<br /> [ 167.303044] drm_fdin-1097 2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40<br /> [ 167.303095] drm_fdin-1097 2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }<br /> [ 167.303159] kworker/-89 11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2<br /> [ 167.303208] kworker/-89 11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin<br /> [ 167.303272] kworker/-89 11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2<br /> [ 167.303321] kworker/-89 11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin<br /> [ 167.303384] kworker/-89 11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660<br /> [ 167.303434] kworker/-89 11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns }<br /> [ 167.303484] kworker/-89 11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked<br /> [ 167.303534] -0 5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040<br /> [ 167.303583] kworker/-89 11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns }<br /> [ 167.303756] kworker/-89 11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns }<br /> [ 167.303806] kworker/-89 11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(engine-&gt;sched_engine-&gt;queue_priority_hint != (-((int)(~0U &gt;&gt; 1)) - 1))<br /> [ 167.303811] ---------------------------------<br /> [ 167.304722] ------------[ cut here ]------------<br /> [ 167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!<br /> [ 167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G W 6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1<br /> [ 167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022<br /> [ 167.304738] Workqueue: i915-unordered retire_work_handler [i915]<br /> [ 16<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Unmap the surface before resetting it on a plane state<br /> <br /> Switch to a new plane state requires unreferencing of all held surfaces.<br /> In the work required for mob cursors the mapped surfaces started being<br /> cached but the variable indicating whether the surface is currently<br /> mapped was not being reset. This leads to crashes as the duplicated<br /> state, incorrectly, indicates the that surface is mapped even when<br /> no surface is present. That&amp;#39;s because after unreferencing the surface<br /> it&amp;#39;s perfectly possible for the plane to be backed by a bo instead of a<br /> surface.<br /> <br /> Reset the surface mapped flag when unreferencing the plane state surface<br /> to fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland:<br /> <br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2<br /> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020<br /> RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]<br /> Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 8b 78 28 e8 e3 f&gt;<br /> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600<br /> RBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920<br /> R10: 0000000000000003 R11: ffff969e7feb3b10 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00<br /> FS: 00007f1e8f1b4180(0000) GS:ffff969e75f00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x171/0x4e0<br /> ? exc_page_fault+0x7f/0x180<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]<br /> drm_atomic_helper_cleanup_planes+0x9b/0xc0<br /> commit_tail+0xd1/0x130<br /> drm_atomic_helper_commit+0x11a/0x140<br /> drm_atomic_commit+0x97/0xd0<br /> ? __pfx___drm_printfn_info+0x10/0x10<br /> drm_atomic_helper_update_plane+0xf5/0x160<br /> drm_mode_cursor_universal+0x10e/0x270<br /> drm_mode_cursor_common+0x102/0x230<br /> ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10<br /> drm_ioctl_kernel+0xb2/0x110<br /> drm_ioctl+0x26d/0x4b0<br /> ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10<br /> ? __pfx_drm_ioctl+0x10/0x10<br /> vmw_generic_ioctl+0xa4/0x110 [vmwgfx]<br /> __x64_sys_ioctl+0x94/0xd0<br /> do_syscall_64+0x61/0xe0<br /> ? __x64_sys_ioctl+0xaf/0xd0<br /> ? syscall_exit_to_user_mode+0x2b/0x40<br /> ? do_syscall_64+0x70/0xe0<br /> ? __x64_sys_ioctl+0xaf/0xd0<br /> ? syscall_exit_to_user_mode+0x2b/0x40<br /> ? do_syscall_64+0x70/0xe0<br /> ? exc_page_fault+0x7f/0x180<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> RIP: 0033:0x7f1e93f279ed<br /> Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 c2 3d 00 f0 ff f&gt;<br /> RSP: 002b:00007ffca0faf600 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 000055db876ed2c0 RCX: 00007f1e93f279ed<br /> RDX: 00007ffca0faf6c0 RSI: 00000000c02464bb RDI: 0000000000000015<br /> RBP: 00007ffca0faf650 R08: 000055db87184010 R09: 0000000000000007<br /> R10: 000055db886471a0 R11: 0000000000000246 R12: 00007ffca0faf6c0<br /> R13: 00000000c02464bb R14: 0000000000000015 R15: 00007ffca0faf790<br /> <br /> Modules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_ine&gt;<br /> CR2: 0000000000000028<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]<br /> Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 8b 78 28 e8 e3 f&gt;<br /> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600<br /> RBP: ffff969d4143<br /> ---truncated---

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix double free of the ha-&gt;vp_map pointer<br /> <br /> Coverity scan reported potential risk of double free of the pointer<br /> ha-&gt;vp_map. ha-&gt;vp_map was freed in qla2x00_mem_alloc(), and again freed<br /> in function qla2x00_mem_free(ha).<br /> <br /> Assign NULL to vp_map and kfree take care of NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix command flush on cable pull<br /> <br /> System crash due to command failed to flush back to SCSI layer.<br /> <br /> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP NOPTI<br /> CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G OE --------- - - 4.18.0-372.9.1.el8.x86_64 #1<br /> Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021<br /> Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]<br /> RIP: 0010:__wake_up_common+0x4c/0x190<br /> Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75<br /> RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086<br /> RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8<br /> R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20<br /> R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> __wake_up_common_lock+0x7c/0xc0<br /> qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]<br /> qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0<br /> ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]<br /> qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200.<br /> ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]<br /> qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1<br /> ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]<br /> qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0<br /> ? __switch_to+0x10c/0x450<br /> ? process_one_work+0x1a7/0x360<br /> qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201.<br /> ? worker_thread+0x1ce/0x390<br /> ? create_worker+0x1a0/0x1a0<br /> qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70<br /> ? kthread+0x10a/0x120<br /> qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8<br /> ? set_kthread_struct+0x40/0x40<br /> qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed.<br /> ? ret_from_fork+0x1f/0x40<br /> qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logout<br /> <br /> The system was under memory stress where driver was not able to allocate an<br /> SRB to carry out error recovery of cable pull. The failure to flush causes<br /> upper layer to start modifying scsi_cmnd. When the system frees up some<br /> memory, the subsequent cable pull trigger another command flush. At this<br /> point the driver access a null pointer when attempting to DMA unmap the<br /> SGL.<br /> <br /> Add a check to make sure commands are flush back on session tear down to<br /> prevent the null pointer access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpm: fix double-free issue in tcpm_port_unregister_pd()<br /> <br /> When unregister pd capabilitie in tcpm, KASAN will capture below double<br /> -free issue. The root cause is the same capabilitiy will be kfreed twice,<br /> the first time is kfreed by pd_capabilities_release() and the second time<br /> is explicitly kfreed by tcpm_port_unregister_pd().<br /> <br /> [ 3.988059] BUG: KASAN: double-free in tcpm_port_unregister_pd+0x1a4/0x3dc<br /> [ 3.995001] Free of addr ffff0008164d3000 by task kworker/u16:0/10<br /> [ 4.001206]<br /> [ 4.002712] CPU: 2 PID: 10 Comm: kworker/u16:0 Not tainted 6.8.0-rc5-next-20240220-05616-g52728c567a55 #53<br /> [ 4.012402] Hardware name: Freescale i.MX8QXP MEK (DT)<br /> [ 4.017569] Workqueue: events_unbound deferred_probe_work_func<br /> [ 4.023456] Call trace:<br /> [ 4.025920] dump_backtrace+0x94/0xec<br /> [ 4.029629] show_stack+0x18/0x24<br /> [ 4.032974] dump_stack_lvl+0x78/0x90<br /> [ 4.036675] print_report+0xfc/0x5c0<br /> [ 4.040289] kasan_report_invalid_free+0xa0/0xc0<br /> [ 4.044937] __kasan_slab_free+0x124/0x154<br /> [ 4.049072] kfree+0xb4/0x1e8<br /> [ 4.052069] tcpm_port_unregister_pd+0x1a4/0x3dc<br /> [ 4.056725] tcpm_register_port+0x1dd0/0x2558<br /> [ 4.061121] tcpci_register_port+0x420/0x71c<br /> [ 4.065430] tcpci_probe+0x118/0x2e0<br /> <br /> To fix the issue, this will remove kree() from tcpm_port_unregister_pd().