[PATCH v10] media: dvb-core: extirpate defective and unsafe ULE debug block

[PATCH v10] media: dvb-core: extirpate defective and unsafe ULE debug block

[Breno Rodrigues Alves]

Completely purge the unmaintained DVB_ULE_DEBUG code block from
dvb_net.c and its Kconfig definition to eliminate severe lockless race
conditions and clean up the unused function signature parameter.

Assisted-by: OpenCode AI
Signed-off-by: Breno Rodrigues Alves <breno3011alves@gmail.com>
---
 drivers/media/dvb-core/Kconfig   | 11 ---------
 drivers/media/dvb-core/dvb_net.c | 42 +-------------------------------
 2 files changed, 1 insertion(+), 52 deletions(-)

diff --git a/drivers/media/dvb-core/Kconfig b/drivers/media/dvb-core/Kconfig
index 8b3f2d53c..c6a97add8 100644
--- a/drivers/media/dvb-core/Kconfig
+++ b/drivers/media/dvb-core/Kconfig
@@ -67,14 +67,3 @@ config DVB_DEMUX_SECTION_LOSS_LOG
 
 	  If you are unsure about this, say N here.
 
-config DVB_ULE_DEBUG
-	bool "Enable DVB net ULE packet debug messages"
-	depends on DVB_CORE
-	help
-	  Enable extra log messages meant to detect problems while
-	  handling DVB network ULE packet loss inside the Kernel.
-
-	  Should not be enabled on normal cases, as logs can
-	  be very verbose.
-
-	  If you are unsure about this, say N here.
diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
index a2159b2bc..5060b8866 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++;
@@ -843,7 +803,7 @@ static void dvb_net_ule(struct net_device *dev, const u8 *buf, size_t buf_len)
 				       *(tail - 2) << 8 |
 				       *(tail - 1);
 
-			dvb_net_ule_check_crc(&h, iov, ule_crc, expected_crc);
+			dvb_net_ule_check_crc(&h, ule_crc, expected_crc);
 
 			/* Prepare for next SNDU. */
 			reset_ule(h.priv);
-- 
2.43.0

Re: [PATCH v10] media: dvb-core: extirpate defective and unsafe ULE debug block

[sashiko-bot]

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

New issues:
- [Low] Mismatch between function definition and function call resulting in a compile error.

Pre-existing issues:
- [Critical] Missing payload length check for the MAC address when the ULE D-bit is 0 leads to an out-of-bounds read and an integer underflow of skb->len.
- [High] Error paths in `dvb_net_add_if()` fail to clear `dvbnet->state`, leading to a NULL pointer dereference on teardown.
- [High] Workqueues are flushed before `unregister_netdev()`, allowing concurrent re-arming and subsequent Use-After-Free.
- [High] Dangling `net_device` and Use-After-Free on hardware hot-unplug if the interface is UP.
- [High] Concurrent execution of interface removal causes a Double Free of `net_device`.
- [High] Out-of-bounds read in ULE extension header parsing due to missing boundary checks.
- [Medium] The multicast list workqueue starts the demux feed without checking if the network interface is running, leading to packet processing on an offline interface.
--

commit a436ecc632e24cc55cee7118d76ed42b70d862e1
Author: Breno Rodrigues Alves <breno3011alves@gmail.com>

media: dvb-core: extirpate defective and unsafe ULE debug block

Completely purge the unmaintained DVB_ULE_DEBUG code block from
dvb_net.c and its Kconfig definition to eliminate severe lockless race
conditions and clean up the unused function signature parameter.

> diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
> index a2159b2bc1766..5060b8866de8a 100644
> --- a/drivers/media/dvb-core/dvb_net.c
> +++ b/drivers/media/dvb-core/dvb_net.c
[ ... ]
> @@ -843,7 +803,7 @@ static void dvb_net_ule(struct net_device *dev, const u8 *buf, size_t buf_len)
>  				       *(tail - 2) << 8 |
>  				       *(tail - 1);
>  
> -			dvb_net_ule_check_crc(&h, iov, ule_crc, expected_crc);
> +			dvb_net_ule_check_crc(&h, ule_crc, expected_crc);

[Severity: Low]
Does this change cause a compilation error? The patch updates the call site
to pass 3 arguments, but it looks like the function definition of
dvb_net_ule_check_crc() was not updated and still expects 4 arguments:

static void dvb_net_ule_check_crc(struct dvb_net_ule_handle *h,
                                  struct kvec iov[3],
                                  u32 ule_crc, u32 expected_crc)

>  			/* Prepare for next SNDU. */
>  			reset_ule(h.priv);

[Severity: High]
This is a pre-existing issue, but can the error paths in dvb_net_add_if()
cause a null pointer dereference on teardown?

dvb_net_add_if() calls get_if() to reserve a slot by setting
dvbnet->state[if_num] = 1, but if alloc_netdev() fails:

	net = alloc_netdev(sizeof(struct dvb_net_priv), "dvb",
			   NET_NAME_UNKNOWN, dvb_net_setup);
	if (!net)
		return -ENOMEM;

It returns an error without resetting dvbnet->state back to 0, leaving
dvbnet->device[if_num] as null.

Later, when dvb_net_release() or the remove interface ioctl cleans up, it
iterates over active slots and calls dvb_net_remove_if():

	struct net_device *net = dvbnet->device[num];
	struct dvb_net_priv *priv;

	if (!dvbnet->state[num])
		return -EINVAL;
	priv = netdev_priv(net);
	if (priv->in_use)

Is it possible for netdev_priv(net) to blindly dereference this null pointer
and cause an oops?

[Severity: High]
This is a pre-existing issue, but it looks like flushing workqueues before
unregister_netdev() allows concurrent re-arming and a subsequent
use-after-free.

In dvb_net_remove_if():

	flush_work(&priv->set_multicast_list_wq);
	flush_work(&priv->restart_net_feed_wq);
	pr_info("removed network interface %s\n", net->name);
	unregister_netdev(net);
	dvbnet->state[num]=0;
	dvbnet->device[num] = NULL;
	free_netdev(net);

The workqueues are flushed before unregister_netdev() without holding the
rtnl lock. Concurrently, an interface up command could take the rtnl lock,
mark the interface up, and schedule a workqueue after the flush completes.

When unregister_netdev() executes, it takes the rtnl lock and brings the
interface down, but does not cancel the newly queued work. After it returns,
free_netdev(net) is called.

Could this allow the workqueue to execute wq_set_multicast_list() on freed
memory?

[Severity: High]
This is a pre-existing issue, but could hardware hot-unplug lead to a
dangling net_device and use-after-free if the interface is administratively
up?

When dvb_net_remove_if() is called, it returns early if the interface is up:

	priv = netdev_priv(net);
	if (priv->in_use)
		return -EBUSY;

However, dvb_net_release() ignores this return value:

	for (i=0; i<DVB_NET_DEVICES_MAX; i++) {
		if (!dvbnet->state[i])
			continue;
		dvb_net_remove_if(dvbnet, i);
	}

This ignores the busy status and continues teardown, freeing the backend dvb
adapter structures.

Does the net_device remain actively registered in the network stack, causing
a use-after-free if subsequent packet reception or state changes dereference
the freed pointers?

[Severity: High]
This is a pre-existing issue, but it appears concurrent execution of
interface removal causes a double free of net_device.

In dvb_net_remove_if(), the validation check is unprotected:

	if (!dvbnet->state[num])
		return -EINVAL;

While the remove interface ioctl path is protected by a mutex,
dvb_net_release() invokes removal concurrently without holding it:

		dvb_net_remove_if(dvbnet, i);

Could both threads validate dvbnet->state[num] == 1 simultaneously and
proceed to sequentially call unregister_netdev() and free_netdev() on the
exact same net_device pointer?

[Severity: Medium]
This is a pre-existing issue, but is it safe for wq_set_multicast_list() to
force the data feed on without checking if the interface is running?

	netif_addr_unlock_bh(dev);
	dvb_net_feed_start(dev);

If the interface is administratively brought down, dev_close() flushes
multicast filters and schedules this workqueue.

Does the workqueue execute after the interface is functionally down and
unconditionally call dvb_net_feed_start(dev), which could bombard the
offline interface with packets?

[Severity: High]
This is a pre-existing issue, but is there an out-of-bounds read in
handle_one_ule_extension() due to missing boundary checks?

		ext_len = hlen << 1;
		/* Process the optional extension header according to its type. */
		if (ule_optional_ext_handlers[htype])
			(void)ule_optional_ext_handlers[htype]( p );
		p->ule_next_hdr += ext_len;
		p->ule_sndu_type = ntohs( *(__be16 *)(p->ule_next_hdr-2) );

Is the pointer advanced by an attacker-controlled length and dereferenced to
read the next header type without verifying that the new pointer remains
within the boundaries of the received skb payload?

[Severity: Critical]
This is a pre-existing issue, but can a missing payload length check for the
mac address when the ule d-bit is 0 lead to an out-of-bounds read and an
integer underflow of skb->len?

dvb_net_ule_new_payload() validates length using:

		if (h->priv->ule_sndu_len < 5) {

This fails to account for packets where the d-bit is 0, which mandate a
6-byte mac address. If a crafted packet with ule_sndu_len = 5 and d-bit = 0
arrives, dvb_net_ule_check_crc() executes:

	/* CRC32 was OK, so remove it from skb. */
	h->priv->ule_skb->tail -= 4;
	h->priv->ule_skb->len -= 4;

	if (!h->priv->ule_dbit) {
		...
		skb_copy_from_linear_data(h->priv->ule_skb, dest_addr,
					  ETH_ALEN);
		skb_pull(h->priv->ule_skb, ETH_ALEN);
	}

If the skb length is 3, unconditional subtraction of 4 causes an integer
underflow.

Could skb_copy_from_linear_data() then copy 6 bytes, leaking uninitialized
kernel heap into the destination mac address?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260905132812.8521-1-breno3011alves@gmail.com?part=1