When simple_write_to_buffer() succeeds, it returns the number of bytes
actually copied to the buffer, which may be less than the requested
'count' if the buffer size is insufficient. However, the current code
incorrectly uses 'count' as the index for null termination instead of
the actual bytes copied, leading to out-of-bound write.
Add a check for the count and use the return value as the index.
Found via static analysis. This is similar to the
commit da9374819eb3 ("iio: backend: fix out-of-bound write")
Fixes: b1c5d68ea66e ("iio: dac: ad3552r-hs: add support for internal ramp")
Cc: stable(a)vger.kernel.org
Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com>
---
drivers/iio/dac/ad3552r-hs.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/dac/ad3552r-hs.c b/drivers/iio/dac/ad3552r-hs.c
index 41b96b48ba98..a9578afa7015 100644
--- a/drivers/iio/dac/ad3552r-hs.c
+++ b/drivers/iio/dac/ad3552r-hs.c
@@ -549,12 +549,15 @@ static ssize_t ad3552r_hs_write_data_source(struct file *f,
guard(mutex)(&st->lock);
+ if (count >= sizeof(buf))
+ return -ENOSPC;
+
ret = simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, userbuf,
count);
if (ret < 0)
return ret;
- buf[count] = '\0';
+ buf[ret] = '\0';
ret = match_string(dbgfs_attr_source, ARRAY_SIZE(dbgfs_attr_source),
buf);
--
2.39.5 (Apple Git-154)
A recent change fixed device reference leaks when looking up drm
platform device driver data during bind() but failed to remove a partial
fix which had been added by commit 80805b62ea5b ("drm/mediatek: Fix
kobject put for component sub-drivers").
This results in a reference imbalance on component bind() failures and
on unbind() which could lead to a user-after-free.
Make sure to only drop the references after retrieving the driver data
by effectively reverting the previous partial fix.
Note that holding a reference to a device does not prevent its driver
data from going away so there is no point in keeping the reference.
Fixes: 1f403699c40f ("drm/mediatek: Fix device/node reference count leaks in mtk_drm_get_all_drm_priv")
Reported-by: Sjoerd Simons <sjoerd(a)collabora.com>
Link: https://lore.kernel.org/r/20251003-mtk-drm-refcount-v1-1-3b3f2813b0db@colla…
Cc: stable(a)vger.kernel.org
Cc: Ma Ke <make24(a)iscas.ac.cn>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 384b0510272c..a94c51a83261 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -686,10 +686,6 @@ static int mtk_drm_bind(struct device *dev)
for (i = 0; i < private->data->mmsys_dev_num; i++)
private->all_drm_private[i]->drm = NULL;
err_put_dev:
- for (i = 0; i < private->data->mmsys_dev_num; i++) {
- /* For device_find_child in mtk_drm_get_all_priv() */
- put_device(private->all_drm_private[i]->dev);
- }
put_device(private->mutex_dev);
return ret;
}
@@ -697,18 +693,12 @@ static int mtk_drm_bind(struct device *dev)
static void mtk_drm_unbind(struct device *dev)
{
struct mtk_drm_private *private = dev_get_drvdata(dev);
- int i;
/* for multi mmsys dev, unregister drm dev in mmsys master */
if (private->drm_master) {
drm_dev_unregister(private->drm);
mtk_drm_kms_deinit(private->drm);
drm_dev_put(private->drm);
-
- for (i = 0; i < private->data->mmsys_dev_num; i++) {
- /* For device_find_child in mtk_drm_get_all_priv() */
- put_device(private->all_drm_private[i]->dev);
- }
put_device(private->mutex_dev);
}
private->mtk_drm_bound = false;
--
2.49.1
The code in bmc150-accel-core.c unconditionally calls
bmc150_accel_set_interrupt() in the iio_buffer_setup_ops,
such as on the runtime PM resume path giving a kernel
splat like this if the device has no interrupts:
Unable to handle kernel NULL pointer dereference at virtual
address 00000001 when read
CPU: 0 UID: 0 PID: 393 Comm: iio-sensor-prox Not tainted
6.18.0-rc1-postmarketos-stericsson-00001-g6b43386e3737 #73 PREEMPT
Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)
PC is at bmc150_accel_set_interrupt+0x98/0x194
LR is at __pm_runtime_resume+0x5c/0x64
(...)
Call trace:
bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108
bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc
__iio_update_buffers from enable_store+0x84/0xc8
enable_store from kernfs_fop_write_iter+0x154/0x1b4
kernfs_fop_write_iter from do_iter_readv_writev+0x178/0x1e4
do_iter_readv_writev from vfs_writev+0x158/0x3f4
vfs_writev from do_writev+0x74/0xe4
do_writev from __sys_trace_return+0x0/0x10
This bug seems to have been in the driver since the beginning,
but it only manifests recently, I do not know why.
Cc: stable(a)vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
---
drivers/iio/accel/bmc150-accel-core.c | 5 +++++
drivers/iio/accel/bmc150-accel.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c
index 3c5d1560b163..f4421a3b0ef2 100644
--- a/drivers/iio/accel/bmc150-accel-core.c
+++ b/drivers/iio/accel/bmc150-accel-core.c
@@ -523,6 +523,10 @@ static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i,
const struct bmc150_accel_interrupt_info *info = intr->info;
int ret;
+ /* We do not always have an IRQ */
+ if (!data->has_irq)
+ return 0;
+
if (state) {
if (atomic_inc_return(&intr->users) > 1)
return 0;
@@ -1696,6 +1700,7 @@ int bmc150_accel_core_probe(struct device *dev, struct regmap *regmap, int irq,
}
if (irq > 0) {
+ data->has_irq = true;
ret = devm_request_threaded_irq(dev, irq,
bmc150_accel_irq_handler,
bmc150_accel_irq_thread_handler,
diff --git a/drivers/iio/accel/bmc150-accel.h b/drivers/iio/accel/bmc150-accel.h
index 7a7baf52e595..6e9bb69a1fd4 100644
--- a/drivers/iio/accel/bmc150-accel.h
+++ b/drivers/iio/accel/bmc150-accel.h
@@ -59,6 +59,7 @@ enum bmc150_accel_trigger_id {
struct bmc150_accel_data {
struct regmap *regmap;
struct regulator_bulk_data regulators[2];
+ bool has_irq;
struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
struct bmc150_accel_trigger triggers[BMC150_ACCEL_TRIGGERS];
struct mutex mutex;
---
base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
change-id: 20251027-fix-bmc150-7e568122b265
Best regards,
--
Linus Walleij <linus.walleij(a)linaro.org>
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
[ Upstream commit f7e37affbc9085f2b77ccb6596521a44eabf7505 ]
Add Intel Wildcat Lake SPI serial flash PCI ID to the list of supported
devices.
Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Link: https://patch.msgid.link/20251020145415.3377022-4-mika.westerberg@linux.int…
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
LLM Generated explanations, may be completely bogus:
## BACKPORT ANALYSIS COMPLETE
**Backport Status: YES**
---
## DETAILED ANALYSIS
### 1. COMMIT CHARACTERIZATION
**Type**: Hardware enablement (PCI device ID addition)
**Code Changes**:
- Single line addition to `drivers/spi/spi-intel-pci.c`
- Adds PCI device ID `0x4d23` (Intel Wildcat Lake SPI serial flash)
- Maps to existing `cnl_info` configuration structure
- No behavioral changes to existing code paths
### 2. SEMANTIC CODE ANALYSIS FINDINGS
#### Tools Used:
- **Read**: Examined the complete file structure (drivers/spi/spi-intel-
pci.c:68-99)
- **Grep**: Located PCI device table usage and MODULE_DEVICE_TABLE macro
- **Git analysis**: Reviewed commit history and backport precedents
#### Impact Scope Analysis:
- **Direct impact**: Only affects systems with PCI ID 0x4d23 (Wildcat
Lake hardware)
- **Caller analysis**: The PCI device table is used by the kernel's PCI
subsystem for automatic device-driver matching
- **Dependency analysis**: Uses `cnl_info` structure (drivers/spi/spi-
intel-pci.c:38-41), which has existed since 2022
- **Risk assessment**: Zero risk to existing hardware - new entry only
triggers on matching PCI ID
### 3. BACKPORT PRECEDENT (Strong Evidence)
I found multiple similar commits that **WERE backported** to stable
trees:
**Example 1 - Lunar Lake-M** (commit ec33549be99fe):
```
commit ec33549be99fe25c6927c8b3d6ed13918b27656e
Author: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Commit: Sasha Levin <sashal(a)kernel.org> [STABLE MAINTAINER]
spi: intel-pci: Add support for Lunar Lake-M SPI serial flash
[ Upstream commit 8f44e3808200c1434c26ef459722f88f48b306df ]
```
**Example 2 - Granite Rapids** (commit 60446b5e74865):
```
commit 60446b5e74865acff1af5f2d89d99551c8e6e2c1
Author: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Commit: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [STABLE
MAINTAINER]
spi: intel-pci: Add support for Granite Rapids SPI serial flash
[ Upstream commit 9855d60cfc720ff32355484c119acafd3c4dc806 ]
```
**Key Finding**: Both commits were backported to stable trees by stable
maintainers (Sasha Levin, Greg Kroah-Hartman) **despite having NO
explicit stable tags** in the original commits.
### 4. STABLE TREE COMPLIANCE
**Positive Factors**:
- ✅ Fixes a real user problem (Wildcat Lake users cannot access SPI
flash on stable kernels)
- ✅ Extremely low risk (single line, static table entry)
- ✅ No architectural changes
- ✅ No dependencies on unreleased features
- ✅ Follows established backporting pattern for PCI ID additions
- ✅ "Obviously correct" - uses tested configuration from 20+ other Intel
platforms
**Considerations**:
- ⚠️ Technically a "new feature" (new hardware support)
- ✅ However, PCI ID additions are a **special exception** routinely
accepted by stable maintainers
- ✅ Hardware enablement is considered "fixing" missing support for
existing hardware
### 5. DEPENDENCY VERIFICATION
- **cnl_info structure**: Present since 2022, exists in all stable
kernels that would receive this backport
- **PCI_VDEVICE macro**: Standard kernel infrastructure
- **intel_spi_probe()**: Core function, no recent changes that would
conflict
- **Clean backport**: No conflicts expected with any stable kernel
version
### 6. RISK ANALYSIS
**Regression Risk**: **MINIMAL**
- Only triggered when PCI ID 0x4d23 is detected
- No effect on systems without Wildcat Lake hardware
- Uses well-tested code path (cnl_info shared with 20+ other platforms)
- No user-space API changes
**Testing Coverage**:
- Same code path used by numerous Intel platforms (Ice Lake, Tiger Lake,
Alder Lake, etc.)
- Configuration structure (cnl_info) battle-tested across multiple
generations
### 7. COMMIT MESSAGE ANALYSIS
The commit message is:
- ✅ Clear and descriptive
- ✅ Identifies specific hardware (Intel Wildcat Lake)
- ✅ Consistent with previous similar commits
- ❌ No "Fixes:" tag (not applicable - this is new hardware support)
- ❌ No "Cc: stable(a)vger.kernel.org" tag (but precedent shows this
doesn't prevent backporting)
---
## RECOMMENDATION
**YES - This commit SHOULD be backported to stable kernel trees**
### Rationale:
1. **Strong precedent**: Multiple similar PCI ID additions for Intel
platforms (Lunar Lake, Granite Rapids, Arrow Lake) have been
backported to stable trees by stable maintainers
2. **User benefit**: Enables critical SPI flash functionality for
Wildcat Lake hardware owners running stable kernels
3. **Minimal risk**: Single-line change to static table with no impact
on existing hardware
4. **Well-established pattern**: PCI ID additions for hardware
enablement are routinely accepted for stable backports as they "fix"
missing hardware support
5. **Clean backport**: No dependencies or conflicts expected
### Target Stable Trees:
- All currently maintained stable kernels (6.17.x, 6.16.x, 6.15.x, etc.)
- The commit is from v6.18-rc3, so it would benefit users on any stable
kernel before 6.18
drivers/spi/spi-intel-pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-intel-pci.c b/drivers/spi/spi-intel-pci.c
index 4b63cb98df9cc..4bb158a23349e 100644
--- a/drivers/spi/spi-intel-pci.c
+++ b/drivers/spi/spi-intel-pci.c
@@ -75,6 +75,7 @@ static const struct pci_device_id intel_spi_pci_ids[] = {
{ PCI_VDEVICE(INTEL, 0x38a4), (unsigned long)&bxt_info },
{ PCI_VDEVICE(INTEL, 0x43a4), (unsigned long)&cnl_info },
{ PCI_VDEVICE(INTEL, 0x4b24), (unsigned long)&bxt_info },
+ { PCI_VDEVICE(INTEL, 0x4d23), (unsigned long)&cnl_info },
{ PCI_VDEVICE(INTEL, 0x4da4), (unsigned long)&bxt_info },
{ PCI_VDEVICE(INTEL, 0x51a4), (unsigned long)&cnl_info },
{ PCI_VDEVICE(INTEL, 0x54a4), (unsigned long)&cnl_info },
--
2.51.0
In thermal_of_cm_lookup(), of_parse_phandle() returns a device node with
its reference count incremented. The caller is responsible for releasing
this reference when the node is no longer needed.
Add of_node_put(tr_np) to fix the reference leaks.
Found via static analysis.
Fixes: 3fd6d6e2b4e8 ("thermal/of: Rework the thermal device tree initialization")
Cc: stable(a)vger.kernel.org
Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com>
---
drivers/thermal/thermal_of.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c
index 1a51a4d240ff..2bb1b8e471cf 100644
--- a/drivers/thermal/thermal_of.c
+++ b/drivers/thermal/thermal_of.c
@@ -284,8 +284,11 @@ static bool thermal_of_cm_lookup(struct device_node *cm_np,
int count, i;
tr_np = of_parse_phandle(child, "trip", 0);
- if (tr_np != trip->priv)
+ if (tr_np != trip->priv) {
+ of_node_put(tr_np);
continue;
+ }
+ of_node_put(tr_np);
/* The trip has been found, look up the cdev. */
count = of_count_phandle_with_args(child, "cooling-device",
--
2.39.5 (Apple Git-154)