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

media: chips-media: wave5: Fix memory leak on codecinfo allocation failure

In wave5vpuopenenc() and wave5vpuopendec(), a vpu instance is allocated via kzalloc(). If the subsequent allocation for inst->codecinfo fails, the functions return -ENOMEM without freeing the previously allocated instance, causing a memory leak.

Fix this by calling kfree() on the instance in this error path to ensure it is properly released.

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

media: chips-media: wave5: Fix PM runtime usage count underflow

Replace pmruntimeputsync() with pmruntimedontuseautosuspend() in the remove path to properly pair with pmruntimeuseautosuspend() from probe. This allows pmruntimedisable() to handle reference count cleanup correctly regardless of current suspend state.

The driver calls pmruntimeputsync() unconditionally in remove, but the device may already be suspended due to autosuspend configured in probe. When autosuspend has already suspended the device, the usage count is 0, and pmruntimeputsync() decrements it to -1.

This causes the following warning on module unload:

------------[ cut here ]------------ WARNING: CPU: 1 PID: 963 at kernel/kthread.c:1430 kthreaddestroyworker+0x84/0x98 ... vdec 30210000.video-codec: Runtime PM usage count underflow!

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

media: chips-media: wave5: Fix device cleanup order to prevent kernel panic

Move video device unregistration to the beginning of the remove function to ensure all video operations are stopped before cleaning up the worker thread and disabling PM runtime. This prevents hardware register access after the device has been powered down.

In polling mode, the hrtimer periodically triggers wave5vputimercallback() which queues work to the kthread worker. The worker executes wave5vpuirqworkfn() which reads hardware registers via wave5vdireadregister().

The original cleanup order disabled PM runtime and powered down hardware before unregistering video devices. When autosuspend triggers and powers off the hardware, the video devices are still registered and the worker thread can still be triggered by the hrtimer, causing it to attempt reading registers from powered-off hardware. This results in a bus error (synchronous external abort) and kernel panic.

This causes random kernel panics during encoding operations:

Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP Modules linked in: wave5 rpmsgctrl rpmsgchar ... CPU: 0 UID: 0 PID: 1520 Comm: vpuirqthread Tainted: G M W pc : wave5vdireadregister+0x10/0x38 [wave5] lr : wave5vpuirqworkfn+0x28/0x60 [wave5] Call trace: wave5vdireadregister+0x10/0x38 [wave5] kthreadworkerfn+0xd8/0x238 kthread+0x104/0x120 retfromfork+0x10/0x20 Code: aa1e03e9 d503201f f9416800 8b214000 (b9400000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: synchronous external abort: Fatal exception