| Message ID | 20260614165630.3896-8-birenpandya@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-23828-sunxi=pue.re@lists.linux.dev>
X-Original-To: noreply@patchwork.local
Delivered-To: noreply@patchwork.local
Received: from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114])
by mxe881.netcup.net (Postfix) with ESMTPS id 37A051C024F
for <noreply@patchwork.local>; Sun, 14 Jun 2026 18:57:20 +0200 (CEST)
Authentication-Results: mxe881;
dkim=pass header.d=gmail.com;
spf=pass (sender IP is 172.105.105.114)
smtp.mailfrom=linux-sunxi+bounces-23828-noreply=patchwork.local@lists.linux.dev
smtp.helo=tor.lore.kernel.org
Received-SPF: pass (mxe881: domain of lists.linux.dev designates
172.105.105.114 as permitted sender) client-ip=172.105.105.114;
envelope-from=linux-sunxi+bounces-23828-noreply=patchwork.local@lists.linux.dev;
helo=tor.lore.kernel.org;
Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org
[100.90.174.1])
by tor.lore.kernel.org (Postfix) with ESMTP id 845A5300564E
for <noreply@patchwork.local>; Sun, 14 Jun 2026 16:57:13 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id CDAA73955EC;
Sun, 14 Jun 2026 16:57:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.b="QAyLNGbs"
X-Original-To: linux-sunxi@lists.linux.dev
Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com
[209.85.214.181])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABFFB3921D0
for <linux-sunxi@lists.linux.dev>; Sun, 14 Jun 2026 16:57:11 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
arc=none smtp.client-ip=209.85.214.181
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1781456232; cv=none;
b=PS946cdfMx4P0DMZqggTJfNUDWyf2A+BvnWc58j4Fz6G4YcBqtUMkFbeAMvTipTGEQfdx9SkWaOO5esapbVzxAZnqcYkkevyHDtZpETO7fVdYqvKWUW6fer/41SW1OSRdYh2KIdUWbhD+U9fUeCekJ7NOKHjXe5x6BYq8nx8Nd0=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1781456232; c=relaxed/simple;
bh=7Zhy1mQVW1t/ztSSKPcZqS28xrO83pxbCfwKTPiB0+Q=;
h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
MIME-Version;
b=h/4O8HTa5NNpEMZbNgHH05FsSjKg9QUx67KTZsY4VDp4LSQESLG0LZhLPpbZXr441zr1ELjJzrrW//OzXFR+jgMl7kSr3Z+cuaMj+UFaoFTUmpNThlrLUUNt9lqD+1s2voUNZuOfBbASqzzRdx/NdqGaE5YwLMZnybi47JWkxvg=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=gmail.com;
spf=pass smtp.mailfrom=gmail.com;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.b=QAyLNGbs; arc=none smtp.client-ip=209.85.214.181
Authentication-Results: smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: smtp.subspace.kernel.org;
spf=pass smtp.mailfrom=gmail.com
Received: by mail-pl1-f181.google.com with SMTP id
d9443c01a7336-2bf0ddaf50fso14425175ad.1
for <linux-sunxi@lists.linux.dev>;
Sun, 14 Jun 2026 09:57:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20251104; t=1781456231; x=1782061031;
darn=lists.linux.dev;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=QY5Ip+P8KRx1IM1Wpd7OwQvhD0XfR0winv2zlXLefIQ=;
b=QAyLNGbsRcS6vVg8QFjvpSzmFlWURTwqIcDJndLuHGLSdKKj+JsMkCn56y+dEXJyHc
HXssZKXxSBa5+gB7ndFKUcN9soqR88XtRvH//cnthGlFF9+X8qMLZ7AoBdZIi8nvIrjo
4DESej4up4etUkIyGiVFAwvKBcsCs3flc1cYpAKlt4C1Mk2bpEAyYBIuKoGtFSfm3JxT
HZYAxzVnFp/kGTnmFUKz9NBsdd6TcOsFP4nRvN+73a6mEThYM7ywrxjEC7Xvc6QFHQfb
EyAnWQhb5XYpIiZfV0tiiCxPV9YBRFy96cRwBTXxqwBQwqrYxASzhE7xY62tWyMPJsng
vcWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1781456231; x=1782061031;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from
:to:cc:subject:date:message-id:reply-to;
bh=QY5Ip+P8KRx1IM1Wpd7OwQvhD0XfR0winv2zlXLefIQ=;
b=WRr0oiL5IgzkbzaClp6ofrwiPsgheEoo2wkVd5MveROpFaJE2mySGvCq9DJjUTFCDf
X7E1ATfrWsvvsvoX7NlpnFjRXtdwhbTzuKrr+L/b/6SkaWefBHE/TIRAZTnq/yAevwGU
EFTRvNe2IKg0GLRTXRyFrF24HgylN8NLlkoK0b/A4tmFSIkfT6ratPex1iotd5kY/iFt
skoCTyJM8MfYbN0rQzPzAyGumllxNVKTDAg00kJkZTcWZw7g/dR8JeNUt/ZR53R1O+6Y
QiCwaBR/1AUlBojmoXjJydRStvB3olCcAJIucGCotR1cv0IrY0pnFV4gWu86m5AcYele
mLYw==
X-Forwarded-Encrypted: i=1;
AFNElJ8YNsyI6CkO7Ax3LiAdn3T3Qzi9StRj90+Oza8lAiD0vMMJpYOcTXW5JAx9Jy1roCOCW6L3qK0qT/EmKA==@lists.linux.dev
X-Gm-Message-State: AOJu0YyOzRC37yhejClYKK3RjsnObNSmecyB2gB9jdXaMeStxPEkz7dF
FpRnCI8UOlbBwA+6vl4kny6Ro/n7peHctI5G4LTcFJp0n9TaWGFlA4+H
X-Gm-Gg: Acq92OFGuIxYpPtIXBskHgQ7WDuLONMXOYbc426Y9UZS/SCOYUoeSXJU0ANN06ZuZiU
kxvqhz5/E7r/j1reejsW4gSspB/r7PK3bK2zibp2MwyYu5N01n6yrzDkMb2Em4zFz3+k9SLSL8F
APqrJYh3zFGkOGQsToWtTzFJGUaSZphEgRrFLnruhWkbME+ZnG81mfj6duJIl9NQEbZ1ghbGyVL
49FWP4izTAsL6NSEZa5irrqc9cF56fPZ6//vw8Bag6WuKqTpVSeOmZcZtE08LYannhDP8RauVKW
tk/IdD45ib5ctoPaHgRnO1shu8MQUr6za872+W25vtqR+76TDx83NiUpAT/w/n8g1TvuaxfmMok
Y5E7RU9jaVe+DBS8jr3nfhBHK1F6cy72+8tozIR74oKI8c1Y/IzZR451vI/PK7wDWPAJYT0mpO1
bYD87vP/1aEep8ezmwv/jGR2umTQTRLsbccHBd0bJOjRouT6cIhCOqHSSLbc9xYQg=
X-Received: by 2002:a17:902:d48f:b0:2c2:1982:5270 with SMTP id
d9443c01a7336-2c6641e28f9mr86805045ad.21.1781456231128;
Sun, 14 Jun 2026 09:57:11 -0700 (PDT)
Received: from localhost.localdomain ([49.207.217.37])
by smtp.gmail.com with ESMTPSA id
d9443c01a7336-2c42f2e5590sm85284025ad.14.2026.06.14.09.57.06
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Sun, 14 Jun 2026 09:57:10 -0700 (PDT)
From: Biren Pandya <birenpandya@gmail.com>
To: linux-media@vger.kernel.org,
mchehab@kernel.org
Cc: Biren Pandya <birenpandya@gmail.com>,
Maxime Ripard <mripard@kernel.org>,
Chen-Yu Tsai <wens@kernel.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: [PATCH 07/22] media: platform: sun4i_csi: Add missing
media_entity_cleanup()
Date: Sun, 14 Jun 2026 22:25:44 +0530
Message-ID: <20260614165630.3896-8-birenpandya@gmail.com>
X-Mailer: git-send-email 2.50.1
In-Reply-To: <20260614165630.3896-1-birenpandya@gmail.com>
References: <20260614165630.3896-1-birenpandya@gmail.com>
Precedence: bulk
X-Mailing-List: linux-sunxi@lists.linux.dev
List-Id: <linux-sunxi.lists.linux.dev>
List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Server: rspamd-worker-8404
X-Spamd-Result: default: False [0.34 / 15.00];
BAYES_HAM(-5.50)[99.99%];
RBL_SENDERSCORE(2.00)[172.105.105.114:from];
SUSPICIOUS_RECIPS(1.50)[];
DMARC_POLICY_SOFTFAIL(1.00)[gmail.com : SPF not aligned (relaxed),
No valid DKIM,none];
MID_CONTAINS_FROM(1.00)[];
R_MISSING_CHARSET(0.50)[];
MAILLIST(-0.15)[generic];
MIME_GOOD(-0.10)[text/plain];
BAD_REP_POLICIES(0.10)[];
HAS_LIST_UNSUB(-0.01)[];
PRECEDENCE_BULK(0.00)[];
FORGED_SENDER_MAILLIST(0.00)[];
TAGGED_RCPT(0.00)[];
FUZZY_BLOCKED(0.00)[rspamd.com];
DBL_BLOCKED_OPENRESOLVER(0.00)[tor.lore.kernel.org:rdns,tor.lore.kernel.org:helo];
FREEMAIL_CC(0.00)[gmail.com,kernel.org,sholland.org,linux.intel.com,lists.infradead.org,lists.linux.dev,vger.kernel.org];
FROM_HAS_DN(0.00)[];
RCVD_COUNT_FIVE(0.00)[6];
ARC_ALLOW(0.00)[subspace.kernel.org:s=arc-20240116:i=1];
R_SPF_ALLOW(0.00)[+ip4:172.105.105.114];
RCPT_COUNT_SEVEN(0.00)[11];
FREEMAIL_FROM(0.00)[gmail.com];
TO_DN_SOME(0.00)[];
FROM_NEQ_ENVFROM(0.00)[birenpandya@gmail.com,linux-sunxi@lists.linux.dev];
FORGED_RECIPIENTS_MAILLIST(0.00)[];
RCVD_TLS_LAST(0.00)[];
MIME_TRACE(0.00)[0:+];
TAGGED_FROM(0.00)[bounces-23828-noreply=patchwork.local];
ASN(0.00)[asn:63949, ipnet:172.105.96.0/20, country:SG];
RCVD_VIA_SMTP_AUTH(0.00)[]
X-Rspamd-Queue-Id: 37A051C024F
X-MORS-Enabled: yes
X-MORS-DOMAIN: patchwork.local
X-MORS-HOSTING: hosting172546
X-MORS-USER: hosting172546
X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?=
|
| Series |
None
|
|
Commit Message
Biren Pandya
June 14, 2026, 4:55 p.m. UTC
Fixes: 577bbf23b758 ("media: sunxi: Add A10 CSI driver")
Signed-off-by: Biren Pandya <birenpandya@gmail.com>
---
drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
Comments
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] The error path in `sun4i_csi_probe` fails to clean up the V4L2 async notifier, leaking the async connection memory and fwnode reference.
- [High] If `sun4i_csi_notify_complete` fails after registering the video device, the node is exposed to userspace but not cleaned up on probe abort, leading to a Use-After-Free.
- [Medium] Early error paths in `sun4i_csi_probe` fail to call `media_device_cleanup()`, leaking IDA internal structures and mutexes initialized by `media_device_init()`.
--
commit 0bea5104c6b556049740c1a93c1ab60799f7c769
Author: Biren Pandya <birenpandya@gmail.com>
media: platform: sun4i_csi: Add missing media_entity_cleanup()
This commit adds calls to media_entity_cleanup() in the sun4i_csi probe
error paths and the remove function to properly release media entities.
> diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
> index e53a07b770b7e..f50d97ca795f8 100644
> --- a/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
> +++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
> @@ -242,11 +242,11 @@ static int sun4i_csi_probe(struct platform_device *pdev)
> vdev->entity.ops = &sun4i_csi_video_entity_ops;
> ret = media_entity_pads_init(&vdev->entity, 1, &csi->vdev_pad);
> if (ret < 0)
> - return ret;
> + goto err_clean_subdev_entity;
>
> ret = sun4i_csi_dma_register(csi, irq);
> if (ret)
> - goto err_clean_pad;
> + goto err_clean_vdev_entity;
>
> ret = sun4i_csi_notifier_init(csi);
> if (ret)
[ ... ]
> @@ -266,6 +266,10 @@ static int sun4i_csi_probe(struct platform_device *pdev)
> media_device_unregister(&csi->mdev);
> sun4i_csi_dma_unregister(csi);
[Severity: High]
This isn't a bug introduced by this patch, but does the error path in
sun4i_csi_probe() fail to clean up the V4L2 async notifier, leaking the
async connection memory and fwnode reference?
sun4i_csi_notifier_init() allocates memory for a v4l2_async_connection via
v4l2_async_nf_add_fwnode_remote() and takes a reference to the fwnode. If
v4l2_async_nf_register() subsequently fails, the error path jumps to
err_unregister_media. However, neither this label nor the cascading error
paths below it call v4l2_async_nf_cleanup(&csi->notifier).
[Severity: High]
This is a pre-existing issue, but could this error path lead to a
use-after-free if sun4i_csi_notify_complete() fails after registering
the video device?
In sun4i_csi_notify_complete(), sun4i_csi_v4l2_register() successfully
registers the /dev/videoX node. If a subsequent step (such as
media_device_register() or media_create_pad_link()) fails, the function
returns an error without rolling back and unregistering the video device.
This failure bubbles up, causing v4l2_async_nf_register() in probe to fail.
The probe error path here entirely omits vb2_video_unregister_device().
Consequently, devres frees the csi memory (which embeds csi->vdev), but
the /dev/videoX node remains active. If userspace opens the stranded video
node, the kernel will dereference the freed csi struct via
video_drvdata(file).
> +err_clean_vdev_entity:
> + media_entity_cleanup(&vdev->entity);
> +err_clean_subdev_entity:
> + media_entity_cleanup(&subdev->entity);
> err_clean_pad:
> media_device_cleanup(&csi->mdev);
[Severity: Medium]
This is a pre-existing issue, but do early error paths in sun4i_csi_probe()
leak IDA internal structures and mutexes initialized by media_device_init()?
For example, if devm_platform_ioremap_resource() fails:
drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c:sun4i_csi_probe() {
...
media_device_init(&csi->mdev);
csi->v4l.mdev = &csi->mdev;
csi->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(csi->regs))
return PTR_ERR(csi->regs);
...
}
It returns directly instead of jumping to the err_clean_pad cleanup label
seen above, bypassing the necessary media_device_cleanup(&csi->mdev) call.
diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c index e53a07b770b7..f50d97ca795f 100644 --- a/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c +++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c @@ -242,11 +242,11 @@ static int sun4i_csi_probe(struct platform_device *pdev) vdev->entity.ops = &sun4i_csi_video_entity_ops; ret = media_entity_pads_init(&vdev->entity, 1, &csi->vdev_pad); if (ret < 0) - return ret; + goto err_clean_subdev_entity; ret = sun4i_csi_dma_register(csi, irq); if (ret) - goto err_clean_pad; + goto err_clean_vdev_entity; ret = sun4i_csi_notifier_init(csi); if (ret) @@ -266,6 +266,10 @@ static int sun4i_csi_probe(struct platform_device *pdev) media_device_unregister(&csi->mdev); sun4i_csi_dma_unregister(csi); +err_clean_vdev_entity: + media_entity_cleanup(&vdev->entity); +err_clean_subdev_entity: + media_entity_cleanup(&subdev->entity); err_clean_pad: media_device_cleanup(&csi->mdev); @@ -282,6 +286,8 @@ static void sun4i_csi_remove(struct platform_device *pdev) vb2_video_unregister_device(&csi->vdev); media_device_unregister(&csi->mdev); sun4i_csi_dma_unregister(csi); + media_entity_cleanup(&csi->subdev.entity); + media_entity_cleanup(&csi->vdev.entity); media_device_cleanup(&csi->mdev); }