Re: [PATCH v1 1/1] media: tda18250: Use %*ph to print small buffer

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but an unconditional dereference of `client->dev.platform_data` can cause a kernel Oops.
--

commit 1ea3356f8c26d9844c17f495f65f794b5140a6ef
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

media: tda18250: Use %*ph to print small buffer

This commit updates the driver to use the %*ph format specifier for
printing a small buffer as a hex string.

> diff --git a/drivers/media/tuners/tda18250.c b/drivers/media/tuners/tda18250.c
> --- a/drivers/media/tuners/tda18250.c
> +++ b/drivers/media/tuners/tda18250.c
> @@ -804,8 +804,7 @@ static int tda18250_probe(struct i2c_client *client)

[Severity: High]
This is a pre-existing issue, but can an unconditional dereference of
client->dev.platform_data cause a kernel oops?

In tda18250_probe(), cfg is initialized from platform_data and immediately
dereferenced without a prior null check:

static int tda18250_probe(struct i2c_client *client)
{
        struct tda18250_config *cfg = client->dev.platform_data;
        struct dvb_frontend *fe = cfg->fe;

If the device is instantiated without platform data, such as when a root
user manually creates the device via the i2c new_device sysfs interface or
if bound via an incomplete device tree node, cfg will be null.

Does reading the fe member from a null cfg pointer result in a concrete
null pointer dereference bringing the system down?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603111724.230522-1-andriy.shevchenko@linux.intel.com?part=1