linux-kernel - Re: camss NULL-deref on power on with 6.12-rc2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aLFvpj2co-jFW_GE@hovoldconsulting.com>
Date: Fri, 29 Aug 2025 11:15:18 +0200
From: Johan Hovold <johan@...nel.org>
To: Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>
Cc: Robert Foss <rfoss@...nel.org>, Todor Tomov <todor.too@...il.com>,
	Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
	linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: camss NULL-deref on power on with 6.12-rc2

Hi Vladimir,

On Sun, Aug 24, 2025 at 11:42:26PM +0300, Vladimir Zapolskiy wrote:

> On 10/11/24 12:33, Johan Hovold wrote:

> > This morning I hit the below NULL-deref in camss when booting a 6.12-rc2
> > kernel on the Lenovo ThinkPad X13s.
> > 
> > I booted the same kernel another 50 times without hitting it again it so
> > it may not be a regression, but simply an older, hard to hit bug.
> > 
> > Hopefully you can figure out what went wrong from just staring at the
> > oops and code.

> > [    5.657860] ov5675 24-0010: failed to get HW configuration: -517
> > [    5.676183] vreg_l6q: Bringing 2800000uV into 1800000-1800000uV
> > 
> > [    6.517689] qcom-camss ac5a000.camss: Adding to iommu group 22
> > 
> > [    6.589201] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030

> > [    6.594868] CPU: 0 UID: 0 PID: 557 Comm: v4l_id Not tainted 6.12.0-rc2 #165
> > [    6.594871] Hardware name: LENOVO 21BYZ9SRUS/21BYZ9SRUS, BIOS N3HET87W (1.59 ) 12/05/2023

> > [    6.594915] Call trace:
> > [    6.594915]  camss_find_sensor+0x20/0x74 [qcom_camss]
> > [    6.594920]  camss_get_pixel_clock+0x18/0x60 [qcom_camss]
> > [    6.594924]  vfe_get+0xb8/0x504 [qcom_camss]
> > [    6.594931]  vfe_set_power+0x30/0x58 [qcom_camss]
> > [    6.594936]  pipeline_pm_power_one+0x13c/0x150 [videodev]
> > [    6.594951]  pipeline_pm_power.part.0+0x58/0xf4 [videodev]
> > [    6.594960]  v4l2_pipeline_pm_use+0x58/0x94 [videodev]
> > [    6.594969]  v4l2_pipeline_pm_get+0x14/0x20 [videodev]
> > [    6.594978]  video_open+0x78/0xf4 [qcom_camss]
> > [    6.594982]  v4l2_open+0x80/0x120 [videodev]
> 
> As you remember the problem has been discussed in the past [1], for
> your information the issue has been indirectly fixed in v6.17-rc1 by
> getting rid of v4l2_pipeline_pm_get() from .open, see commit
> 164202f68203 ("media: qcom: camss: Power pipeline only when streaming").
> 
> Still the old race is left unresolved, and it could lead to a NULL
> pointer dereference, but practically it would be close to impossible to
> reproduce it, since one more step of starting a video stream is needed.

Thanks for the update. Would still be good to fix the underlying issue
properly, especially since I don't think we know exactly how big that
race window is, and also to prevent further hard-to-track down issues
from being introduced later.

Johan

> [1] https://lore.kernel.org/all/aE_hlGHkRZqFFacR@hovoldconsulting.com/