Correct a copy-paste typo in the MediaTek interconnect Makefile that
mapped mt8196.o to CONFIG_INTERCONNECT_MTK_MT8195 instead of MT8196.
Assisted-by: OpenCode AI
Signed-off-by: Breno Rodrigues Alves <redacted>
---
drivers/interconnect/mediatek/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/interconnect/mediatek/Makefile b/drivers/interconnect/mediatek/Makefile
index 6bd656668..64170ab16 100644
--- a/drivers/interconnect/mediatek/Makefile
+++ b/drivers/interconnect/mediatek/Makefile
@@ -3,4 +3,4 @@
obj-$(CONFIG_INTERCONNECT_MTK_DVFSRC_EMI) += icc-emi.o
obj-$(CONFIG_INTERCONNECT_MTK_MT8183) += mt8183.o
obj-$(CONFIG_INTERCONNECT_MTK_MT8195) += mt8195.o
-obj-$(CONFIG_INTERCONNECT_MTK_MT8195) += mt8196.o
+obj-$(CONFIG_INTERCONNECT_MTK_MT8196) += mt8196.o
--
2.43.0
Fix a Makefile typo that incorrectly placed the mt6316-regulator object
under the old CONFIG_REGULATOR_MT6315 configuration flag.
Assisted-by: OpenCode AI
Signed-off-by: Breno Rodrigues Alves <redacted>
---
drivers/regulator/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 5a764cec8..f81d1f31a 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -107,7 +107,7 @@ obj-$(CONFIG_REGULATOR_MP886X) += mp886x.o
obj-$(CONFIG_REGULATOR_MPQ7920) += mpq7920.o
obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
obj-$(CONFIG_REGULATOR_MT6315) += mt6315-regulator.o
-obj-$(CONFIG_REGULATOR_MT6315) += mt6316-regulator.o
+obj-$(CONFIG_REGULATOR_MT6316) += mt6316-regulator.o
obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6331) += mt6331-regulator.o
obj-$(CONFIG_REGULATOR_MT6332) += mt6332-regulator.o
--
2.43.0
Completely purge the unmaintained DVB_ULE_DEBUG code block from
dvb_net.c to eliminate severe lockless race conditions and buffer overflow
vulnerabilities on global network state variables.
Assisted-by: OpenCode AI
Signed-off-by: Breno Rodrigues Alves <redacted>
---
drivers/leds/Kconfig | 1 -
drivers/media/dvb-core/dvb_net.c | 40 --------------------------------
2 files changed, 41 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index d0d318223..800fbd560 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -873,7 +873,6 @@ config LEDS_UPBOARD
This driver can also be built as a module. If so the module will be
called leds-upboard.
-comment "LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM)"
config LEDS_BLINKM
tristate "LED support for the BlinkM I2C RGB LED"
diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
index a2159b2bc..ae0073b94 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -68,19 +68,6 @@ static inline __u32 iov_crc32( __u32 c, struct kvec *iov, unsigned int cnt )
#define DVB_NET_MULTICAST_MAX 10
-#ifdef DVB_ULE_DEBUG
-/*
- * The code inside DVB_ULE_DEBUG keeps a history of the
- * last 100 TS cells processed.
- */
-static unsigned char ule_hist[100*TS_SZ] = { 0 };
-static unsigned char *ule_where = ule_hist, ule_dump;
-
-static void hexdump(const unsigned char *buf, unsigned short len)
-{
- print_hex_dump_debug("", DUMP_PREFIX_OFFSET, 16, 1, buf, len, true);
-}
-#endif
struct dvb_net_priv {
int in_use;@@ -320,16 +307,6 @@ static int dvb_net_ule_new_ts_cell(struct dvb_net_ule_handle *h)
{
/* We are about to process a new TS cell. */
-#ifdef DVB_ULE_DEBUG
- if (ule_where >= &ule_hist[100*TS_SZ])
- ule_where = ule_hist;
- memcpy(ule_where, h->ts, TS_SZ);
- if (ule_dump) {
- hexdump(ule_where, TS_SZ);
- ule_dump = 0;
- }
- ule_where += TS_SZ;
-#endif
/*
* Check TS h->error conditions: sync_byte, transport_error_indicator,@@ -659,23 +636,6 @@ static void dvb_net_ule_check_crc(struct dvb_net_ule_handle *h,
h->ts_remain > 2 ?
*(unsigned short *)h->from_where : 0);
- #ifdef DVB_ULE_DEBUG
- hexdump(iov[0].iov_base, iov[0].iov_len);
- hexdump(iov[1].iov_base, iov[1].iov_len);
- hexdump(iov[2].iov_base, iov[2].iov_len);
-
- if (ule_where == ule_hist) {
- hexdump(&ule_hist[98*TS_SZ], TS_SZ);
- hexdump(&ule_hist[99*TS_SZ], TS_SZ);
- } else if (ule_where == &ule_hist[TS_SZ]) {
- hexdump(&ule_hist[99*TS_SZ], TS_SZ);
- hexdump(ule_hist, TS_SZ);
- } else {
- hexdump(ule_where - TS_SZ - TS_SZ, TS_SZ);
- hexdump(ule_where - TS_SZ, TS_SZ);
- }
- ule_dump = 1;
- #endif
h->dev->stats.rx_errors++;
h->dev->stats.rx_crc_errors++;--
2.43.0
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [Medium] The patch silently includes an unrelated modification in the LED subsystem Kconfig.
- [Low] The commit removes the `DVB_ULE_DEBUG` code blocks from `dvb_net.c` but fails to remove the corresponding Kconfig option from `drivers/media/dvb-core/Kconfig`.
- [Low] The parameter `iov` in `dvb_net_ule_check_crc()` is now unused after the removal of the debug block.
Pre-existing issues:
- [Critical] The ULE SNDU payload parser lacks robust bounds checking on user-controlled length fields, allowing an attacker to underflow `skb->len` via `skb_pull()` and read/write out-of-bounds memory.
- [High] Dereferencing a casted `unsigned short *` pointer from an unaligned byte stream causes a kernel panic due to alignment faults on strict architectures.
--
commit fe63e38a3f8932fddc46f48a9206976093b6c1c6
Author: Breno Rodrigues Alves [off-list ref]
media: dvb-core: extirpate defective and unsafe ULE debug block
Completely purge the unmaintained DVB_ULE_DEBUG code block from
dvb_net.c to eliminate severe lockless race conditions and buffer overflow
vulnerabilities on global network state variables.
Completely purge the unmaintained DVB_ULE_DEBUG code block from
dvb_net.c to eliminate severe lockless race conditions and buffer overflow
vulnerabilities on global network state variables.
[Severity: Low]
Did this commit miss removing the config DVB_ULE_DEBUG definition from
drivers/media/dvb-core/Kconfig? Leaving it in makes the Kconfig option
selectable but has no effect.
quoted hunk
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index d0d3182236be4..800fbd56093ec 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -873,7 +873,6 @@ config LEDS_UPBOARD
This driver can also be built as a module. If so the module will be
called leds-upboard.
-comment "LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM)"
config LEDS_BLINKM
tristate "LED support for the BlinkM I2C RGB LED"
[Severity: Medium]
Is this unrelated modification in the LED subsystem Kconfig intentional? It
doesn't seem to be documented in the commit message and introduces an
undocumented side effect in an unrelated subsystem.
quoted hunk
diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
index a2159b2bc1766..ae0073b949a50 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
[ ... ]
quoted hunk
@@ -659,23 +636,6 @@ static void dvb_net_ule_check_crc(struct dvb_net_ule_handle *h,
h->ts_remain > 2 ?
*(unsigned short *)h->from_where : 0);
[Severity: High]
This isn't a bug introduced by this patch, but does the unaligned pointer cast
here cause a fatal alignment fault on strict architectures?
In drivers/media/dvb-core/dvb_net.c:dvb_net_ule_check_crc(), when an attacker
sends a ULE packet with an invalid CRC, the error path unsafely casts the
unaligned h->from_where pointer to an unsigned short * and dereferences it:
h->ts_remain > 2 ? *(unsigned short *)h->from_where : 0);
This can cause a kernel panic (Denial of Service) on architectures like SPARC
or older ARM that do not support unaligned accesses.
[Severity: Low]
With the removal of the DVB_ULE_DEBUG block below, is the parameter iov in
dvb_net_ule_check_crc() now unused?
drivers/media/dvb-core/dvb_net.c:dvb_net_ule_check_crc(struct dvb_net_ule_handle *h,
struct kvec iov[3],
u32 ule_crc, u32 expected_crc)
- #ifdef DVB_ULE_DEBUG
- hexdump(iov[0].iov_base, iov[0].iov_len);
- hexdump(iov[1].iov_base, iov[1].iov_len);
- hexdump(iov[2].iov_base, iov[2].iov_len);
-
- if (ule_where == ule_hist) {
- hexdump(&ule_hist[98*TS_SZ], TS_SZ);
- hexdump(&ule_hist[99*TS_SZ], TS_SZ);
- } else if (ule_where == &ule_hist[TS_SZ]) {
- hexdump(&ule_hist[99*TS_SZ], TS_SZ);
- hexdump(ule_hist, TS_SZ);
- } else {
- hexdump(ule_where - TS_SZ - TS_SZ, TS_SZ);
- hexdump(ule_where - TS_SZ, TS_SZ);
- }
- ule_dump = 1;
- #endif
h->dev->stats.rx_errors++;
h->dev->stats.rx_crc_errors++;
[Severity: Critical]
This is a pre-existing issue, but does the ULE SNDU payload parser lack
robust bounds checking on user-controlled length fields?
In drivers/media/dvb-core/dvb_net.c:dvb_net_ule_new_payload(), the minimum
length check fails to account for the 6-byte MAC address when ule_dbit is 0:
if (h->priv->ule_sndu_len < 5) {
If an attacker sends a malformed packet with ule_dbit == 0 and a payload
length of 5, after the 4-byte CRC is removed in dvb_net_ule_check_crc(),
skb->len becomes 1. Then skb_pull(h->priv->ule_skb, ETH_ALEN) subtracts 6,
causing skb->len to underflow:
drivers/media/dvb-core/dvb_net.c:dvb_net_ule_check_crc() {
...
if (!h->priv->ule_dbit) {
...
skb_pull(h->priv->ule_skb, ETH_ALEN);
...
}
Similarly, in handle_ule_extensions(), the loop accumulates lengths without
validating they fit in the payload buffer:
drivers/media/dvb-core/dvb_net.c:handle_ule_extensions() {
...
total_ext_len += l;
...
}
This unbounded length is then passed to skb_pull() in dvb_net_ule_check_crc(),
again causing an skb->len underflow:
drivers/media/dvb-core/dvb_net.c:dvb_net_ule_check_crc() {
...
skb_pull(h->priv->ule_skb, l);
...
}
This allows an attacker to underflow skb->len and read or write
out-of-bounds memory, leading to network stack memory corruption.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260905124434.6163-1-breno3011alves@gmail.com?part=3