CVE-2023-53455

In the Linux kernel, the following vulnerability has been resolved:

drm/vc4: drop all currently held locks if deadlock happens

If vc4hdmiresetlink() returns -EDEADLK, it means that a deadlock happened in the locking context. This situation should be addressed by dropping all currently held locks and block until the contended lock becomes available. Currently, vc4 is not dealing with the deadlock properly, producing the following output when PROVELOCKING is enabled:

[ 825.612809] ------------[ cut here ]------------ [ 825.612852] WARNING: CPU: 1 PID: 116 at drivers/gpu/drm/drmmodesetlock.c:276 drmmodesetdroplocks+0x60/0x68 [drm] [ 825.613458] Modules linked in: 8021q mrp garp stp llc raspberrypicpufreq brcmfmac brcmutil crct10difce hciuart cfg80211 btqca btbcm bluetooth vc4 raspberrypihwmon sndsochdmicodec cec clkraspberrypi ecdhgeneric drmdisplayhelper ecc rfkill drmdmahelper drmkmshelper pwmbcm2835 bcm2835thermal bcm2835rng rngcore i2cbcm2835 drm fuse iptables xtables ipv6 [ 825.613735] CPU: 1 PID: 116 Comm: kworker/1:2 Tainted: G W 6.1.0-rc6-01399-g941aae326315 #3 [ 825.613759] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 825.613777] Workqueue: events outputpollexecute [drmkmshelper] [ 825.614038] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 825.614063] pc : drmmodesetdroplocks+0x60/0x68 [drm] [ 825.614603] lr : drmhelperprobedetect+0x120/0x1b4 [drmkmshelper] [ 825.614829] sp : ffff800008313bf0 [ 825.614844] x29: ffff800008313bf0 x28: ffffcd7778b8b000 x27: 0000000000000000 [ 825.614883] x26: 0000000000000001 x25: 0000000000000001 x24: ffff677cc35c2758 [ 825.614920] x23: ffffcd7707d01430 x22: ffffcd7707c3edc7 x21: 0000000000000001 [ 825.614958] x20: 0000000000000000 x19: ffff800008313c10 x18: 000000000000b6d3 [ 825.614995] x17: ffffcd777835e214 x16: ffffcd7777cef870 x15: fffff81000000000 [ 825.615033] x14: 0000000000000000 x13: 0000000000000099 x12: 0000000000000002 [ 825.615070] x11: 72917988020af800 x10: 72917988020af800 x9 : 72917988020af800 [ 825.615108] x8 : ffff677cc665e0a8 x7 : d00a8c180000110c x6 : ffffcd77774c0054 [ 825.615145] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 [ 825.615181] x2 : ffff677cc55e1880 x1 : ffffcd7777cef8ec x0 : ffff800008313c10 [ 825.615219] Call trace: [ 825.615232] drmmodesetdroplocks+0x60/0x68 [drm] [ 825.615773] drmhelperprobedetect+0x120/0x1b4 [drmkmshelper] [ 825.616003] outputpollexecute+0xe4/0x224 [drmkmshelper] [ 825.616233] processonework+0x2b4/0x618 [ 825.616264] workerthread+0x24c/0x464 [ 825.616288] kthread+0xec/0x110 [ 825.616310] retfromfork+0x10/0x20 [ 825.616335] irq event stamp: 7634 [ 825.616349] hardirqs last enabled at (7633): [<ffffcd777831ee90>] rawspinunlockirq+0x3c/0x78 [ 825.616384] hardirqs last disabled at (7634): [<ffffcd7778315a78>] __schedule+0x134/0x9f0 [ 825.616411] softirqs last enabled at (7630): [<ffffcd7707aacea0>] localbhenable+0x4/0x30 [ipv6] [ 825.617019] softirqs last disabled at (7618): [<ffffcd7707aace70>] localbhdisable+0x4/0x30 [ipv6] [ 825.617586] ---[ end trace 0000000000000000 ]---

Therefore, deal with the deadlock as suggested by [1], using the function drmmodesetbackoff().

[1] https://docs.kernel.org/gpu/drm-kms.html?highlight=kms#kms-locking