From: Alex Guo alexguo1023@gmail.com
[ Upstream commit ce5cac69b2edac3e3246fee03e8f4c2a1075238b ]
In dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add check on msg[0].len to prevent crash. Similar issue occurs when access msg[1].buf[0] and msg[1].buf[1].
Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Signed-off-by: Alex Guo alexguo1023@gmail.com Link: https://lore.kernel.org/r/20250616013231.730221-1-alexguo1023@gmail.com Signed-off-by: Mauro Carvalho Chehab mchehab+huawei@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**YES**
This commit should be backported to stable kernel trees for the following reasons:
## Security Bug Fix This commit fixes a **null pointer dereference vulnerability** that can be triggered by user-controlled input through the I2C subsystem. The vulnerability occurs in `dib7090p_rw_on_apb()` when:
1. **Write path (num == 1)**: The code accesses `msg[0].buf[1]` and `msg[0].buf[2]` without checking if `msg[0].len >= 3`: ```c dib7000p_write_word(state, apb_address, ((msg[0].buf[1] << 8) | (msg[0].buf[2]))); ```
2. **Read path (num != 1)**: The code accesses `msg[1].buf[0]` and `msg[1].buf[1]` without checking if `msg[1].len >= 2`: ```c msg[1].buf[0] = (word >> 8) & 0xff; msg[1].buf[1] = (word) & 0xff; ```
## User-Controlled Attack Vector The `msg` parameter comes from user-space through the I2C ioctl interface, making this a **user-triggerable vulnerability**. A malicious or buggy application can pass: - `msg[0].buf = NULL` with `msg[0].len = 0` - Or a valid buffer with insufficient length
This would cause the kernel to dereference memory beyond the allocated buffer or dereference NULL, leading to a kernel crash or potential privilege escalation.
## Minimal and Contained Fix The fix is: - **Small**: Only adds 4 lines of bounds checking - **Contained**: Changes are limited to a single function - **Low risk**: Simply returns `-EOPNOTSUPP` when buffer lengths are insufficient - **No architectural changes**: Pure defensive programming addition
## Follows Established Pattern The commit references a similar fix (`0ed554fd769a`) for the same class of vulnerability in `az6027_i2c_xfer()`, which was already accepted and likely backported. This shows: - The issue is recognized as security-relevant - The fix pattern is established and tested - Multiple DVB drivers have this vulnerability class
## Meets Stable Criteria According to stable tree rules, this commit: - ✅ Fixes a real bug (null-ptr-deref crash) - ✅ Is small and self-contained (4 lines added) - ✅ Has minimal risk of regression (defensive checks only) - ✅ Addresses a security issue (user-triggerable kernel crash) - ✅ No new features or architectural changes
The vulnerability allows unprivileged users with access to DVB devices to crash the kernel, making it a significant security issue that warrants backporting to all maintained stable kernels that contain the vulnerable code.
drivers/media/dvb-frontends/dib7000p.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/media/dvb-frontends/dib7000p.c b/drivers/media/dvb-frontends/dib7000p.c index b40daf242046..360a2d7dd3ed 100644 --- a/drivers/media/dvb-frontends/dib7000p.c +++ b/drivers/media/dvb-frontends/dib7000p.c @@ -2256,8 +2256,12 @@ static int dib7090p_rw_on_apb(struct i2c_adapter *i2c_adap, u16 word;
if (num == 1) { /* write */ + if (msg[0].len < 3) + return -EOPNOTSUPP; dib7000p_write_word(state, apb_address, ((msg[0].buf[1] << 8) | (msg[0].buf[2]))); } else { + if (msg[1].len < 2) + return -EOPNOTSUPP; word = dib7000p_read_word(state, apb_address); msg[1].buf[0] = (word >> 8) & 0xff; msg[1].buf[1] = (word) & 0xff;