| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()
The variable codec->regmap is often protected by the lock
codec->regmap_lock when is accessed. However, it is accessed without
holding the lock when is accessed in snd_hdac_regmap_sync():
if (codec->regmap)
In my opinion, this may be a harmful race, because if codec->regmap is
set to NULL right after the condition is checked, a null-pointer
dereference can occur in the called function regcache_sync():
map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c
To fix this possible null-pointer dereference caused by data race, the
mutex_lock coverage is extended to protect the if statement as well as the
function call to regcache_sync().
[ Note: the lack of the regmap_lock itself is harmless for the current
codec driver implementations, as snd_hdac_regmap_sync() is only for
PM runtime resume that is prohibited during the codec probe.
But the change makes the whole code more consistent, so it's merged
as is -- tiwai ] |
| In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: mt8183: Add back SSPM related clocks
This reverts commit 860690a93ef23b567f781c1b631623e27190f101.
On the MT8183, the SSPM related clocks were removed claiming a lack of
usage. This however causes some issues when the driver was converted to
the new simple-probe mechanism. This mechanism allocates enough space
for all the clocks defined in the clock driver, not the highest index
in the DT binding. This leads to out-of-bound writes if their are holes
in the DT binding or the driver (due to deprecated or unimplemented
clocks). These errors can go unnoticed and cause memory corruption,
leading to crashes in unrelated areas, or nothing at all. KASAN will
detect them.
Add the SSPM related clocks back to the MT8183 clock driver to fully
implement the DT binding. The SSPM clocks are for the power management
co-processor, and should never be turned off. They are marked as such. |
| In the Linux kernel, the following vulnerability has been resolved:
Drivers: vmbus: Check for channel allocation before looking up relids
relid2channel() assumes vmbus channel array to be allocated when called.
However, in cases such as kdump/kexec, not all relids will be reset by the host.
When the second kernel boots and if the guest receives a vmbus interrupt during
vmbus driver initialization before vmbus_connect() is called, before it finishes,
or if it fails, the vmbus interrupt service routine is called which in turn calls
relid2channel() and can cause a null pointer dereference.
Print a warning and error out in relid2channel() for a channel id that's invalid
in the second kernel. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ena: fix shift-out-of-bounds in exponential backoff
The ENA adapters on our instances occasionally reset. Once recently
logged a UBSAN failure to console in the process:
UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13
shift exponent 32 is too large for 32-bit type 'unsigned int'
CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117
Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017
Workqueue: ena ena_fw_reset_device [ena]
Call Trace:
<TASK>
dump_stack_lvl+0x4a/0x63
dump_stack+0x10/0x16
ubsan_epilogue+0x9/0x36
__ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e
? __const_udelay+0x43/0x50
ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena]
wait_for_reset_state+0x54/0xa0 [ena]
ena_com_dev_reset+0xc8/0x110 [ena]
ena_down+0x3fe/0x480 [ena]
ena_destroy_device+0xeb/0xf0 [ena]
ena_fw_reset_device+0x30/0x50 [ena]
process_one_work+0x22b/0x3d0
worker_thread+0x4d/0x3f0
? process_one_work+0x3d0/0x3d0
kthread+0x12a/0x150
? set_kthread_struct+0x50/0x50
ret_from_fork+0x22/0x30
</TASK>
Apparently, the reset delays are getting so large they can trigger a
UBSAN panic.
Looking at the code, the current timeout is capped at 5000us. Using a
base value of 100us, the current code will overflow after (1<<29). Even
at values before 32, this function wraps around, perhaps
unintentionally.
Cap the value of the exponent used for this backoff at (1<<16) which is
larger than currently necessary, but large enough to support bigger
values in the future. |
| In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()
There is a memory leaks problem reported by kmemleak:
unreferenced object 0xffff888102007a00 (size 128):
comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s)
hex dump (first 32 bytes):
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
backtrace:
[<ffffffff8176cecd>] __kmalloc+0x4d/0x150
[<ffffffffa02a9a36>] ubi_eba_create_table+0x76/0x170 [ubi]
[<ffffffffa029764e>] ubi_resize_volume+0x1be/0xbc0 [ubi]
[<ffffffffa02a3321>] ubi_cdev_ioctl+0x701/0x1850 [ubi]
[<ffffffff81975d2d>] __x64_sys_ioctl+0x11d/0x170
[<ffffffff83c142a5>] do_syscall_64+0x35/0x80
[<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
This is due to a mismatch between create and destroy interfaces, and
in detail that "new_eba_tbl" created by ubi_eba_create_table() but
destroyed by kfree(), while will causing "new_eba_tbl->entries" not
freed.
Fix it by replacing kfree(new_eba_tbl) with
ubi_eba_destroy_table(new_eba_tbl) |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix i_disksize exceeding i_size problem in paritally written case
It is possible for i_disksize can exceed i_size, triggering a warning.
generic_perform_write
copied = iov_iter_copy_from_user_atomic(len) // copied < len
ext4_da_write_end
| ext4_update_i_disksize
| new_i_size = pos + copied;
| WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize) // update i_disksize
| generic_write_end
| copied = block_write_end(copied, len) // copied = 0
| if (unlikely(copied < len))
| if (!PageUptodate(page))
| copied = 0;
| if (pos + copied > inode->i_size) // return false
if (unlikely(copied == 0))
goto again;
if (unlikely(iov_iter_fault_in_readable(i, bytes))) {
status = -EFAULT;
break;
}
We get i_disksize greater than i_size here, which could trigger WARNING
check 'i_size_read(inode) < EXT4_I(inode)->i_disksize' while doing dio:
ext4_dio_write_iter
iomap_dio_rw
__iomap_dio_rw // return err, length is not aligned to 512
ext4_handle_inode_extension
WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize) // Oops
WARNING: CPU: 2 PID: 2609 at fs/ext4/file.c:319
CPU: 2 PID: 2609 Comm: aa Not tainted 6.3.0-rc2
RIP: 0010:ext4_file_write_iter+0xbc7
Call Trace:
vfs_write+0x3b1
ksys_write+0x77
do_syscall_64+0x39
Fix it by updating 'copied' value before updating i_disksize just like
ext4_write_inline_data_end() does.
A reproducer can be found in the buganizer link below. |
| In the Linux kernel, the following vulnerability has been resolved:
block: ublk: make sure that block size is set correctly
block size is one very key setting for block layer, and bad block size
could panic kernel easily.
Make sure that block size is set correctly.
Meantime if ublk_validate_params() fails, clear ub->params so that disk
is prevented from being added. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: fsl_mqs: move of_node_put() to the correct location
of_node_put() should have been done directly after
mqs_priv->regmap = syscon_node_to_regmap(gpr_np);
otherwise it creates a reference leak on the success path.
To fix this, of_node_put() is moved to the correct location, and change
all the gotos to direct returns. |
| In the Linux kernel, the following vulnerability has been resolved:
driver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event()
The kfree() should be called when memory fails to be allocated for
cb_data in xlnx_add_cb_for_notify_event(), otherwise there will be
a memory leak, so add kfree() to fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: acpi: Fix possible memory leak of ffh_ctxt
Allocated 'ffh_ctxt' memory leak is possible if the SMCCC version
and conduit checks fail and -EOPNOTSUPP is returned without freeing the
allocated memory.
Fix the same by moving the allocation after the SMCCC version and
conduit checks. |
| In the Linux kernel, the following vulnerability has been resolved:
ubi: ensure that VID header offset + VID header size <= alloc, size
Ensure that the VID header offset + VID header size does not exceed
the allocated area to avoid slab OOB.
BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197
Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555
CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W
6.0.0-1868 #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29
04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x85/0xad lib/dump_stack.c:106
print_address_description mm/kasan/report.c:317 [inline]
print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433
kasan_report+0xa7/0x11b mm/kasan/report.c:495
crc32_body lib/crc32.c:111 [inline]
crc32_le_generic lib/crc32.c:179 [inline]
crc32_le_base+0x58c/0x626 lib/crc32.c:197
ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067
create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317
create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]
ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812
ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601
ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965
ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0x0
RIP: 0033:0x7f96d5cf753d
Code:
RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d
RDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003
RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0
R13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000
</TASK>
Allocated by task 1555:
kasan_save_stack+0x20/0x3d mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:437 [inline]
____kasan_kmalloc mm/kasan/common.c:516 [inline]
__kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525
kasan_kmalloc include/linux/kasan.h:234 [inline]
__kmalloc+0x138/0x257 mm/slub.c:4429
kmalloc include/linux/slab.h:605 [inline]
ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline]
create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295
create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]
ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812
ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601
ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965
ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0x0
The buggy address belongs to the object at ffff88802bb36e00
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 0 bytes to the right of
256-byte region [ffff88802bb36e00, ffff88802bb36f00)
The buggy address belongs to the physical page:
page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000
index:0x0 pfn:0x2bb36
head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0
flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
raw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40
raw: 0000000000000000 00000000001
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe
Use devm_of_iomap() instead of of_iomap() to automatically
handle the unused ioremap region. If any error occurs, regions allocated by
kzalloc() will leak, but using devm_kzalloc() instead will automatically
free the memory using devm_kfree().
Also, fix error handling of hws by adding unregister_hws label, which
unregisters remaining hws when iomap failed. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create
We can't simply free the connector after calling drm_connector_init on it.
We need to clean up the drm side first.
It might not fix all regressions from commit 2b5d1c29f6c4
("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"),
but at least it fixes a memory corruption in error handling related to
that commit. |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix scheduling while atomic in decompression path
[ 16.945668][ C0] Call trace:
[ 16.945678][ C0] dump_backtrace+0x110/0x204
[ 16.945706][ C0] dump_stack_lvl+0x84/0xbc
[ 16.945735][ C0] __schedule_bug+0xb8/0x1ac
[ 16.945756][ C0] __schedule+0x724/0xbdc
[ 16.945778][ C0] schedule+0x154/0x258
[ 16.945793][ C0] bit_wait_io+0x48/0xa4
[ 16.945808][ C0] out_of_line_wait_on_bit+0x114/0x198
[ 16.945824][ C0] __sync_dirty_buffer+0x1f8/0x2e8
[ 16.945853][ C0] __f2fs_commit_super+0x140/0x1f4
[ 16.945881][ C0] f2fs_commit_super+0x110/0x28c
[ 16.945898][ C0] f2fs_handle_error+0x1f4/0x2f4
[ 16.945917][ C0] f2fs_decompress_cluster+0xc4/0x450
[ 16.945942][ C0] f2fs_end_read_compressed_page+0xc0/0xfc
[ 16.945959][ C0] f2fs_handle_step_decompress+0x118/0x1cc
[ 16.945978][ C0] f2fs_read_end_io+0x168/0x2b0
[ 16.945993][ C0] bio_endio+0x25c/0x2c8
[ 16.946015][ C0] dm_io_dec_pending+0x3e8/0x57c
[ 16.946052][ C0] clone_endio+0x134/0x254
[ 16.946069][ C0] bio_endio+0x25c/0x2c8
[ 16.946084][ C0] blk_update_request+0x1d4/0x478
[ 16.946103][ C0] scsi_end_request+0x38/0x4cc
[ 16.946129][ C0] scsi_io_completion+0x94/0x184
[ 16.946147][ C0] scsi_finish_command+0xe8/0x154
[ 16.946164][ C0] scsi_complete+0x90/0x1d8
[ 16.946181][ C0] blk_done_softirq+0xa4/0x11c
[ 16.946198][ C0] _stext+0x184/0x614
[ 16.946214][ C0] __irq_exit_rcu+0x78/0x144
[ 16.946234][ C0] handle_domain_irq+0xd4/0x154
[ 16.946260][ C0] gic_handle_irq.33881+0x5c/0x27c
[ 16.946281][ C0] call_on_irq_stack+0x40/0x70
[ 16.946298][ C0] do_interrupt_handler+0x48/0xa4
[ 16.946313][ C0] el1_interrupt+0x38/0x68
[ 16.946346][ C0] el1h_64_irq_handler+0x20/0x30
[ 16.946362][ C0] el1h_64_irq+0x78/0x7c
[ 16.946377][ C0] finish_task_switch+0xc8/0x3d8
[ 16.946394][ C0] __schedule+0x600/0xbdc
[ 16.946408][ C0] preempt_schedule_common+0x34/0x5c
[ 16.946423][ C0] preempt_schedule+0x44/0x48
[ 16.946438][ C0] process_one_work+0x30c/0x550
[ 16.946456][ C0] worker_thread+0x414/0x8bc
[ 16.946472][ C0] kthread+0x16c/0x1e0
[ 16.946486][ C0] ret_from_fork+0x10/0x20 |
| In the Linux kernel, the following vulnerability has been resolved:
coresight: Fix memory leak in acpi_buffer->pointer
There are memory leaks reported by kmemleak:
...
unreferenced object 0xffff00213c141000 (size 1024):
comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s)
hex dump (first 32 bytes):
04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ...........<!...
00 00 00 00 00 00 00 00 03 00 00 00 10 00 00 00 ................
backtrace:
[<000000004b7c9001>] __kmem_cache_alloc_node+0x2f8/0x348
[<00000000b0fc7ceb>] __kmalloc+0x58/0x108
[<0000000064ff4695>] acpi_os_allocate+0x2c/0x68
[<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0
[<0000000024583908>] acpi_evaluate_object+0x388/0x438
[<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240
[<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight]
...
The ACPI buffer memory (buf.pointer) should be freed. But the buffer
is also used after returning from acpi_get_dsd_graph().
Move the temporary variables buf to acpi_coresight_parse_graph(),
and free it before the function return to prevent memory leak. |
| This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. |
| This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: greybus: audio_helper: remove unused and wrong debugfs usage
In the greybus audio_helper code, the debugfs file for the dapm has the
potential to be removed and memory will be leaked. There is also the
very real potential for this code to remove ALL debugfs entries from the
system, and it seems like this is what will really happen if this code
ever runs. This all is very wrong as the greybus audio driver did not
create this debugfs file, the sound core did and controls the lifespan
of it.
So remove all of the debugfs logic from the audio_helper code as there's
no way it could be correct. If this really is needed, it can come back
with a fixup for the incorrect usage of the debugfs_lookup() call which
is what caused this to be noticed at all. |
| In the Linux kernel, the following vulnerability has been resolved:
media: atomisp: prevent integer overflow in sh_css_set_black_frame()
The "height" and "width" values come from the user so the "height * width"
multiplication can overflow. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dp: add atomic_check to bridge ops
DRM commit_tails() will disable downstream crtc/encoder/bridge if
both disable crtc is required and crtc->active is set before pushing
a new frame downstream.
There is a rare case that user space display manager issue an extra
screen update immediately followed by close DRM device while down
stream display interface is disabled. This extra screen update will
timeout due to the downstream interface is disabled but will cause
crtc->active be set. Hence the followed commit_tails() called by
drm_release() will pass the disable downstream crtc/encoder/bridge
conditions checking even downstream interface is disabled.
This cause the crash to happen at dp_bridge_disable() due to it trying
to access the main link register to push the idle pattern out while main
link clocks is disabled.
This patch adds atomic_check to prevent the extra frame will not
be pushed down if display interface is down so that crtc->active
will not be set neither. This will fail the conditions checking
of disabling down stream crtc/encoder/bridge which prevent
drm_release() from calling dp_bridge_disable() so that crash
at dp_bridge_disable() prevented.
There is no protection in the DRM framework to check if the display
pipeline has been already disabled before trying again. The only
check is the crtc_state->active but this is controlled by usermode
using UAPI. Hence if the usermode sets this and then crashes, the
driver needs to protect against double disable.
SError Interrupt on CPU7, code 0x00000000be000411 -- SError
CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19
Hardware name: Google Lazor (rev3 - 8) (DT)
pstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __cmpxchg_case_acq_32+0x14/0x2c
lr : do_raw_spin_lock+0xa4/0xdc
sp : ffffffc01092b6a0
x29: ffffffc01092b6a0 x28: 0000000000000028 x27: 0000000000000038
x26: 0000000000000004 x25: ffffffd2973dce48 x24: 0000000000000000
x23: 00000000ffffffff x22: 00000000ffffffff x21: ffffffd2978d0008
x20: ffffffd2978d0008 x19: ffffff80ff759fc0 x18: 0000000000000000
x17: 004800a501260460 x16: 0441043b04600438 x15: 04380000089807d0
x14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000438 x10: 00000000000007d0 x9 : ffffffd2973e09e4
x8 : ffffff8092d53300 x7 : ffffff808902e8b8 x6 : 0000000000000001
x5 : ffffff808902e880 x4 : 0000000000000000 x3 : ffffff80ff759fc0
x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffff80ff759fc0
Kernel panic - not syncing: Asynchronous SError Interrupt
CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19
Hardware name: Google Lazor (rev3 - 8) (DT)
Call trace:
dump_backtrace.part.0+0xbc/0xe4
show_stack+0x24/0x70
dump_stack_lvl+0x68/0x84
dump_stack+0x18/0x34
panic+0x14c/0x32c
nmi_panic+0x58/0x7c
arm64_serror_panic+0x78/0x84
do_serror+0x40/0x64
el1h_64_error_handler+0x30/0x48
el1h_64_error+0x68/0x6c
__cmpxchg_case_acq_32+0x14/0x2c
_raw_spin_lock_irqsave+0x38/0x4c
lock_timer_base+0x40/0x78
__mod_timer+0xf4/0x25c
schedule_timeout+0xd4/0xfc
__wait_for_common+0xac/0x140
wait_for_completion_timeout+0x2c/0x54
dp_ctrl_push_idle+0x40/0x88
dp_bridge_disable+0x24/0x30
drm_atomic_bridge_chain_disable+0x90/0xbc
drm_atomic_helper_commit_modeset_disables+0x198/0x444
msm_atomic_commit_tail+0x1d0/0x374
commit_tail+0x80/0x108
drm_atomic_helper_commit+0x118/0x11c
drm_atomic_commit+0xb4/0xe0
drm_client_modeset_commit_atomic+0x184/0x224
drm_client_modeset_commit_locked+0x58/0x160
drm_client_modeset_commit+0x3c/0x64
__drm_fb_helper_restore_fbdev_mode_unlocked+0x98/0xac
drm_fb_helper_set_par+0x74/0x80
drm_fb_helper_hotplug_event+0xdc/0xe0
__drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xac
drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x2c
drm_fb_helper_lastclose+0x20/0x2c
drm_lastclose+0x44/0x6c
drm_release+0x88/0xd4
__fput+0x104/0x220
____fput+0x1c/0x28
task_work_run+0x8c/0x100
d
---truncated--- |
