[PATCH 6.6.y] virtio_net: clamp rss_indir_table_size to VIRTIO_NET_RSS_MAX_TABLE_LEN

[Hyokyung Kim <pulpannie@gmail.com>]

virtnet_probe() reads rss_max_indirection_table_length from the device
config space into vi->rss_indir_table_size and later uses it as the
number of entries to write into the fixed-size 128-entry indirection
table in struct virtio_net_ctrl_rss (in virtnet_init_default_rss(), and
again in virtnet_set_rxfh()/virtnet_get_rxfh()), without validating it
against VIRTIO_NET_RSS_MAX_TABLE_LEN. A malicious or buggy device can
report a length larger than 128 and overflow the array, corrupting
adjacent slab memory. This is reachable at probe time, before the
interface is brought up.

This was fixed upstream by commit 86a48a00efdf ("virtio_net: Support
dynamic rss indirection table size"), which reworks the driver to
allocate the indirection table dynamically. However that change is too
large to backport to stable. Instead, clamp the device-advertised length
to VIRTIO_NET_RSS_MAX_TABLE_LEN: this solves the overflow with minimal
changes.

Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.")
Signed-off-by: Hyokyung Kim <pulpannie@gmail.com>
---

Hi Sasha,

You asked for a tested backport of 86a48a00efdf to 6.6.y and 6.1.y.
While preparing it I found the code does not backport cleanly (there
are many lines needed to change). To minimize the risks of introducing
new bugs, instead I added a small 6-line bounds check on the length the
driver reads from the buggy or malicious device. Sending one patch per
tree.

Tested with KASAN + UBSAN under QEMU (guest 6.6.143), using a virtio-net
device that advertises rss_max_indirection_table_length=512, i.e. larger
than the driver's 128-entry VIRTIO_NET_RSS_MAX_TABLE_LEN.

Before this patch, virtnet_probe() overflows the fixed indirection_table[]
at boot:

  BUG: KASAN: slab-out-of-bounds in virtnet_probe+0x136e/0x1520
  Write of size 2 at addr ff11000003384168 by task swapper/0/1
  CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.143 #2
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
  Call Trace:
   <TASK>
   dump_stack_lvl+0x36/0x50
   print_report+0xcf/0x670
   kasan_report+0xc7/0x100
   virtnet_probe+0x136e/0x1520
   virtio_dev_probe+0x2da/0x470
   really_probe+0x12f/0x420
   __driver_probe_device+0xf8/0x1e0
   driver_probe_device+0x49/0x190
   __driver_attach+0xdd/0x290
   bus_for_each_dev+0xde/0x140
   bus_add_driver+0x14a/0x2e0
   driver_register+0x9b/0x1c0
   virtio_net_driver_init+0x89/0xb0
   do_one_initcall+0x9e/0x2d0

After this patch the length is clamped, the device still probes, the boot
is clean (no KASAN report), and ethtool -x reports a 128-entry table:

  virtio_net virtio0: rss_max_indirection_table_length=512 exceeds max 128, clamping

 drivers/net/virtio_net.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 33f61922c139..ec07e289f0c8 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -4587,6 +4587,12 @@ static int virtnet_probe(struct virtio_device *vdev)
 		vi->rss_indir_table_size =
 			virtio_cread16(vdev, offsetof(struct virtio_net_config,
 				rss_max_indirection_table_length));
+		if (vi->rss_indir_table_size > VIRTIO_NET_RSS_MAX_TABLE_LEN) {
+			dev_warn(&vdev->dev,
+				 "rss_max_indirection_table_length=%u exceeds max %u, clamping\n",
+				 vi->rss_indir_table_size, VIRTIO_NET_RSS_MAX_TABLE_LEN);
+			vi->rss_indir_table_size = VIRTIO_NET_RSS_MAX_TABLE_LEN;
+		}
 	}
 
 	if (vi->has_rss || vi->has_rss_hash_report) {
-- 
2.43.0