AI Trajectory

null

{
  "EnableConfigs": [
    "CAN",
    "CAN_DEV",
    "CAN_VXCAN"
  ],
  "FocusSymbols": [
    "vxcan_newlink",
    "vxcan_dellink"
  ],
  "KMSANReasoning": "The patch series consists of device tree binding updates, hardware driver fixes (sleep mode handling in tcan4x5x, RK3588 support in rockchip_canfd, clock frequency in m_can_pci), and a refcounting/UAF fix in vxcan.c using netdevice_tracker. None of these changes introduce new data structures sent to userspace, modify bounds checking in a way that exposes uninitialized memory, or involve complex uninitialized state. The vxcan.c fix addresses a use-after-free/refcounting issue which is effectively caught by standard KASAN. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies `vxcan_newlink` and `vxcan_dellink` in the virtual CAN tunnel driver (`vxcan`) to use `netdevice_tracker` for peer devices, fixing potential use-after-free or refcounting issues. Since `vxcan` is a virtual network device that can be instantiated via netlink, these changes are easily reachable and should be fuzzed. Other changes in the series are either documentation, typo fixes, or affect hardware-specific drivers (SPI, Rockchip, PCI) not easily emulated.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 3bf9ce15093070312928a5f69561c1a476d7384f\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Mon Aug 17 23:47:05 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml\nindex a077c03300137..81e2b6dfeb023 100644\n--- a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml\n+++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml\n@@ -16,7 +16,9 @@ allOf:\n properties:\n   compatible:\n     oneOf:\n-      - const: rockchip,rk3568v2-canfd\n+      - enum:\n+          - rockchip,rk3568v2-canfd\n+          - rockchip,rk3588-canfd\n       - items:\n           - const: rockchip,rk3568v3-canfd\n           - const: rockchip,rk3568v2-canfd\ndiff --git a/Documentation/devicetree/bindings/net/can/ti,am3517-hecc.yaml b/Documentation/devicetree/bindings/net/can/ti,am3517-hecc.yaml\nnew file mode 100644\nindex 0000000000000..7874e9e492244\n--- /dev/null\n+++ b/Documentation/devicetree/bindings/net/can/ti,am3517-hecc.yaml\n@@ -0,0 +1,64 @@\n+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)\n+%YAML 1.2\n+---\n+$id: http://devicetree.org/schemas/net/can/ti,am3517-hecc.yaml#\n+$schema: http://devicetree.org/meta-schemas/core.yaml#\n+\n+title: Texas Instruments High End CAN Controller (HECC)\n+\n+maintainers:\n+  - Eduard Bostina \u003cegbostina@gmail.com\u003e\n+\n+allOf:\n+  - $ref: can-controller.yaml#\n+\n+properties:\n+  compatible:\n+    const: ti,am3517-hecc\n+\n+  reg:\n+    maxItems: 3\n+\n+  reg-names:\n+    items:\n+      - const: hecc\n+      - const: hecc-ram\n+      - const: mbx\n+\n+  interrupts:\n+    maxItems: 1\n+\n+  clocks:\n+    maxItems: 1\n+\n+  ti,use-hecc1int:\n+    type: boolean\n+    description:\n+      If provided, configures HECC to produce all interrupts on the\n+      HECC1INT interrupt line. By default, the HECC0INT interrupt line\n+      will be used.\n+    default: false\n+\n+  xceiver-supply:\n+    description: Regulator that powers the CAN transceiver.\n+\n+required:\n+  - compatible\n+  - reg\n+  - reg-names\n+  - interrupts\n+  - clocks\n+\n+unevaluatedProperties: false\n+\n+examples:\n+  - |\n+    can@5c050000 {\n+        compatible = \"ti,am3517-hecc\";\n+        reg = \u003c0x5c050000 0x80\u003e,\n+              \u003c0x5c053000 0x180\u003e,\n+              \u003c0x5c052000 0x200\u003e;\n+        reg-names = \"hecc\", \"hecc-ram\", \"mbx\";\n+        interrupts = \u003c24\u003e;\n+        clocks = \u003c\u0026hecc_ck\u003e;\n+    };\ndiff --git a/Documentation/devicetree/bindings/net/can/ti_hecc.txt b/Documentation/devicetree/bindings/net/can/ti_hecc.txt\ndeleted file mode 100644\nindex e0f0a7cfe3293..0000000000000\n--- a/Documentation/devicetree/bindings/net/can/ti_hecc.txt\n+++ /dev/null\n@@ -1,32 +0,0 @@\n-Texas Instruments High End CAN Controller (HECC)\n-================================================\n-\n-This file provides information, what the device node\n-for the hecc interface contains.\n-\n-Required properties:\n-- compatible: \"ti,am3517-hecc\"\n-- reg: addresses and lengths of the register spaces for 'hecc', 'hecc-ram'\n-       and 'mbx'\n-- reg-names :\"hecc\", \"hecc-ram\", \"mbx\"\n-- interrupts: interrupt mapping for the hecc interrupts sources\n-- clocks: clock phandles (see clock bindings for details)\n-\n-Optional properties:\n-- ti,use-hecc1int: if provided configures HECC to produce all interrupts\n-\t\t   on HECC1INT interrupt line. By default HECC0INT interrupt\n-\t\t   line will be used.\n-- xceiver-supply: regulator that powers the CAN transceiver\n-\n-Example:\n-\n-For am3517evm board:\n-\thecc: can@5c050000 {\n-\t\tcompatible = \"ti,am3517-hecc\";\n-\t\treg = \u003c0x5c050000 0x80\u003e,\n-\t\t      \u003c0x5c053000 0x180\u003e,\n-\t\t      \u003c0x5c052000 0x200\u003e;\n-\t\treg-names = \"hecc\", \"hecc-ram\", \"mbx\";\n-\t\tinterrupts = \u003c24\u003e;\n-\t\tclocks = \u003c\u0026hecc_ck\u003e;\n-\t};\ndiff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml\nindex 40835497050a5..18015e60fd6d6 100644\n--- a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml\n+++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml\n@@ -8,7 +8,7 @@ title:\n   Xilinx CAN and CANFD controller\n \n maintainers:\n-  - Appana Durga Kedareswara rao \u003cappana.durga.rao@xilinx.com\u003e\n+  - Harini T \u003charini.t@amd.com\u003e\n \n properties:\n   compatible:\n@@ -53,6 +53,9 @@ properties:\n     $ref: /schemas/types.yaml#/definitions/flag\n     description: CAN TX_OL, TX_TL and RX FIFOs have ECC support(AXI CAN)\n \n+  phys:\n+    maxItems: 1\n+\n required:\n   - compatible\n   - reg\ndiff --git a/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg b/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg\nindex 381323423b4ca..c8cf0bc49b69a 100644\n--- a/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg\n+++ b/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg\n@@ -93,9 +93,9 @@\n    \u003cellipse cx=\"144.827\" cy=\"159.143\" rx=\"10.8866\" ry=\"4.39308\"/\u003e\n    \u003cellipse cx=\"59.4364\" cy=\"142.823\" rx=\"7.36455\" ry=\"4.39308\"/\u003e\n    \u003cellipse cx=\"144.827\" cy=\"129.196\" rx=\"10.8866\" ry=\"4.39308\"/\u003e\n-   \u003cellipse cx=\"143.077\" cy=\"180.53\" rx=\"10.8866\" ry=\"4.39308\"/\u003e\n   \u003c/g\u003e\n-  \u003cellipse cx=\"110.386\" cy=\"180.53\" rx=\"10.8866\" ry=\"4.39308\" fill=\"#ffcb35\" stroke=\"#000\" stroke-linecap=\"square\" stroke-width=\".499999\"/\u003e\n+  \u003cellipse cx=\"110.386\" cy=\"180.53\" rx=\"10.8866\" ry=\"4.39308\" fill=\"#28a4ff\" stroke=\"#000\" stroke-linecap=\"square\" stroke-width=\".499999\"/\u003e\n+  \u003cellipse cx=\"143.077\" cy=\"180.53\" rx=\"10.8866\" ry=\"4.39308\" fill=\"#ffcb35\" stroke=\"#000\" stroke-linecap=\"square\" stroke-width=\".499999\"/\u003e\n   \u003ctext x=\"110.90907\" y=\"179.42688\" font-size=\"3.175px\" xml:space=\"preserve\"\u003e\u003ctspan x=\"110.90907\" y=\"179.42688\" dy=\"0.60000002\" text-align=\"center\" text-anchor=\"middle\"\u003eAccessible\u003c/tspan\u003e\u003ctspan x=\"110.90907\" y=\"183.39563\"\u003e\u003ctspan font-size=\"3.175px\" text-align=\"center\" text-anchor=\"middle\"\u003efor S\u003c/tspan\u003eW\u003c/tspan\u003e\u003c/text\u003e\n   \u003ctext x=\"143.5869\" y=\"179.52795\" xml:space=\"preserve\"\u003e\u003ctspan x=\"143.5869\" y=\"179.52795\" dy=\"1 0 0 0 0 0\" font-family=\"sans-serif\" font-size=\"2.82222px\" text-align=\"center\" text-anchor=\"middle\" style=\"font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal\"\u003eInaccessible\u003c/tspan\u003e\u003ctspan x=\"143.5869\" y=\"183.36786\" font-size=\"3.175px\"\u003e\u003ctspan font-size=\"3.175px\" text-align=\"center\" text-anchor=\"middle\"\u003efor S\u003c/tspan\u003eW\u003c/tspan\u003e\u003c/text\u003e\n   \u003cg font-size=\"3.175px\"\u003e\ndiff --git a/MAINTAINERS b/MAINTAINERS\nindex 991460050da74..6b49a2c80cd5d 100644\n--- a/MAINTAINERS\n+++ b/MAINTAINERS\n@@ -29573,7 +29573,7 @@ F:\tDocumentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml\n F:\tdrivers/net/ethernet/xilinx/xilinx_axienet*\n \n XILINX CAN DRIVER\n-M:\tAppana Durga Kedareswara rao \u003cappana.durga.rao@xilinx.com\u003e\n+M:\tHarini T \u003charini.t@amd.com\u003e\n L:\tlinux-can@vger.kernel.org\n S:\tMaintained\n F:\tDocumentation/devicetree/bindings/net/can/xilinx,can.yaml\ndiff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c\nindex eb856547ae7df..16f80607e150e 100644\n--- a/drivers/net/can/m_can/m_can.c\n+++ b/drivers/net/can/m_can/m_can.c\n@@ -2464,7 +2464,7 @@ struct m_can_classdev *m_can_class_allocate_dev(struct device *dev,\n \t\treturn ERR_PTR(ret);\n \t}\n \n-\tif (dev-\u003eof_node \u0026\u0026 of_property_read_bool(dev-\u003eof_node, \"wakeup-source\"))\n+\tif (dev-\u003eof_node \u0026\u0026 of_property_present(dev-\u003eof_node, \"wakeup-source\"))\n \t\tdevice_set_wakeup_capable(dev, true);\n \n \t/* Get TX FIFO size\ndiff --git a/drivers/net/can/m_can/m_can_pci.c b/drivers/net/can/m_can/m_can_pci.c\nindex eb31ed1f96449..d11a7c88fc32f 100644\n--- a/drivers/net/can/m_can/m_can_pci.c\n+++ b/drivers/net/can/m_can/m_can_pci.c\n@@ -126,7 +126,7 @@ static int m_can_pci_probe(struct pci_dev *pci, const struct pci_device_id *id)\n \tmcan_class-\u003enet-\u003eirq = pci_irq_vector(pci, 0);\n \tmcan_class-\u003epm_clock_support = 1;\n \tmcan_class-\u003epm_wake_source = 0;\n-\tmcan_class-\u003ecan.clock.freq = id-\u003edriver_data;\n+\tmcan_class-\u003ecan.clock.freq = M_CAN_CLOCK_FREQ_EHL;\n \tmcan_class-\u003eirq_edge_triggered = true;\n \tmcan_class-\u003eops = \u0026m_can_pci_ops;\n \n@@ -183,8 +183,8 @@ static SIMPLE_DEV_PM_OPS(m_can_pci_pm_ops,\n \t\t\t m_can_pci_suspend, m_can_pci_resume);\n \n static const struct pci_device_id m_can_pci_id_table[] = {\n-\t{ PCI_VDEVICE(INTEL, 0x4bc1), M_CAN_CLOCK_FREQ_EHL, },\n-\t{ PCI_VDEVICE(INTEL, 0x4bc2), M_CAN_CLOCK_FREQ_EHL, },\n+\t{ PCI_VDEVICE(INTEL, 0x4bc1) },\n+\t{ PCI_VDEVICE(INTEL, 0x4bc2) },\n \t{  }\t/* Terminating Entry */\n };\n MODULE_DEVICE_TABLE(pci, m_can_pci_id_table);\ndiff --git a/drivers/net/can/m_can/tcan4x5x-core.c b/drivers/net/can/m_can/tcan4x5x-core.c\nindex 31cc9d0abd453..a5b8829aa5193 100644\n--- a/drivers/net/can/m_can/tcan4x5x-core.c\n+++ b/drivers/net/can/m_can/tcan4x5x-core.c\n@@ -211,8 +211,31 @@ static int tcan4x5x_write_fifo(struct m_can_classdev *cdev,\n \treturn regmap_bulk_write(priv-\u003eregmap, TCAN4X5X_MRAM_START + addr_offset, val, val_count);\n }\n \n-static int tcan4x5x_power_enable(struct regulator *reg, int enable)\n+static int tcan4x5x_power_enable(struct tcan4x5x_priv *priv, int enable)\n {\n+\tstruct regulator *reg = priv-\u003epower;\n+\n+\t/*\n+\t * Put the device into sleep mode if the RST pin is available,\n+\t * since a wake-up event, RST pin toggle, or power cycle are the only\n+\t * ways to exit sleep mode.\n+\t * Redundant if the regulator is exclusive to this device, but that\n+\t * can't be determined here.\n+\t *\n+\t * Datasheet: TCAN4550, section \"8.4.3 Sleep Mode\"\n+\t * https://www.ti.com/lit/gpn/tcan4550\n+\t */\n+\tif (priv-\u003ereset_gpio \u0026\u0026 !enable) {\n+\t\tint ret;\n+\n+\t\tret = regmap_update_bits(priv-\u003eregmap, TCAN4X5X_CONFIG,\n+\t\t\t\t\t TCAN4X5X_MODE_SEL_MASK,\n+\t\t\t\t\t TCAN4X5X_MODE_SLEEP);\n+\t\tif (ret)\n+\t\t\tdev_err(\u0026priv-\u003espi-\u003edev, \"Setting sleep mode failed %pe\\n\",\n+\t\t\t\tERR_PTR(ret));\n+\t}\n+\n \tif (IS_ERR_OR_NULL(reg))\n \t\treturn 0;\n \n@@ -476,7 +499,7 @@ static int tcan4x5x_can_probe(struct spi_device *spi)\n \t\tgoto out_m_can_class_free_dev;\n \t}\n \n-\tret = tcan4x5x_power_enable(priv-\u003epower, 1);\n+\tret = tcan4x5x_power_enable(priv, 1);\n \tif (ret) {\n \t\tdev_err(\u0026spi-\u003edev, \"Enabling regulator failed %pe\\n\",\n \t\t\tERR_PTR(ret));\n@@ -531,7 +554,7 @@ static int tcan4x5x_can_probe(struct spi_device *spi)\n \treturn 0;\n \n out_power:\n-\ttcan4x5x_power_enable(priv-\u003epower, 0);\n+\ttcan4x5x_power_enable(priv, 0);\n  out_m_can_class_free_dev:\n \tm_can_class_free_dev(mcan_class-\u003enet);\n \treturn ret;\n@@ -543,7 +566,7 @@ static void tcan4x5x_can_remove(struct spi_device *spi)\n \n \tm_can_class_unregister(\u0026priv-\u003ecdev);\n \n-\ttcan4x5x_power_enable(priv-\u003epower, 0);\n+\ttcan4x5x_power_enable(priv, 0);\n \n \tm_can_class_free_dev(priv-\u003ecdev.net);\n }\ndiff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c\nindex 29de0c01e4edc..37c1c22c40c9f 100644\n--- a/drivers/net/can/rockchip/rockchip_canfd-core.c\n+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c\n@@ -50,6 +50,12 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {\n \t\tRKCANFD_QUIRK_CANFD_BROKEN,\n };\n \n+static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3588 = {\n+\t.model = RKCANFD_MODEL_RK3588,\n+\t.quirks = RKCANFD_QUIRK_RK3568_ERRATUM_5 |\n+\t\tRKCANFD_QUIRK_RK3568_ERRATUM_6,\n+};\n+\n static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)\n {\n \tswitch (model) {\n@@ -57,6 +63,8 @@ static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)\n \t\treturn \"rk3568v2\";\n \tcase RKCANFD_MODEL_RK3568V3:\n \t\treturn \"rk3568v3\";\n+\tcase RKCANFD_MODEL_RK3588:\n+\t\treturn \"rk3588\";\n \t}\n \n \treturn \"\u003cunknown\u003e\";\n@@ -148,6 +156,12 @@ static int rkcanfd_set_bittiming(struct rkcanfd_priv *priv)\n \n \trkcanfd_write(priv, RKCANFD_REG_FD_DATA_BITTIMING, reg_dbt);\n \n+\t/* RK3588 CAN-FD BRS works with TDC disabled. */\n+\tif (priv-\u003edevtype_data.model == RKCANFD_MODEL_RK3588) {\n+\t\trkcanfd_write(priv, RKCANFD_REG_TRANSMIT_DELAY_COMPENSATION, 0);\n+\t\treturn 0;\n+\t}\n+\n \ttdco = (priv-\u003ecan.clock.freq / dbt-\u003ebitrate) * 2 / 3;\n \ttdco = min(tdco, FIELD_MAX(RKCANFD_REG_TRANSMIT_DELAY_COMPENSATION_TDC_OFFSET));\n \n@@ -846,6 +860,9 @@ static const struct of_device_id rkcanfd_of_match[] = {\n \t}, {\n \t\t.compatible = \"rockchip,rk3568v3-canfd\",\n \t\t.data = \u0026rkcanfd_devtype_data_rk3568v3,\n+\t}, {\n+\t\t.compatible = \"rockchip,rk3588-canfd\",\n+\t\t.data = \u0026rkcanfd_devtype_data_rk3588,\n \t}, {\n \t\t/* sentinel */\n \t},\ndiff --git a/drivers/net/can/rockchip/rockchip_canfd-rx.c b/drivers/net/can/rockchip/rockchip_canfd-rx.c\nindex 475c0409e215a..24e87daa1df00 100644\n--- a/drivers/net/can/rockchip/rockchip_canfd-rx.c\n+++ b/drivers/net/can/rockchip/rockchip_canfd-rx.c\n@@ -281,7 +281,10 @@ rkcanfd_rx_fifo_get_len(const struct rkcanfd_priv *priv)\n {\n \tconst u32 reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);\n \n-\treturn FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT, reg);\n+\tif (priv-\u003edevtype_data.model == RKCANFD_MODEL_RK3588)\n+\t\treturn FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588, reg);\n+\n+\treturn FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568, reg);\n }\n \n int rkcanfd_handle_rx_int(struct rkcanfd_priv *priv)\ndiff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h\nindex 93131c7d7f54d..95bea9bfd8a2f 100644\n--- a/drivers/net/can/rockchip/rockchip_canfd.h\n+++ b/drivers/net/can/rockchip/rockchip_canfd.h\n@@ -214,7 +214,8 @@\n #define RKCANFD_REG_TXEVENT_FIFO_CTRL_TXE_FIFO_ENABLE BIT(0)\n \n #define RKCANFD_REG_RX_FIFO_CTRL 0x118\n-#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT GENMASK(6, 4)\n+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568 GENMASK(6, 4)\n+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588 GENMASK(7, 5)\n #define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_FULL_WATERMARK GENMASK(3, 1)\n #define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_ENABLE BIT(0)\n \n@@ -331,6 +332,11 @@\n  * rarely with the standard clock of 300 MHz, but almost immediately\n  * at 80 MHz.\n  *\n+ * Tests on the rk3588 show the same empty FIFO condition.\n+ * In that setup rx_fifo_empty_errors increments when the bus\n+ * transitions from idle to high CAN-FD load and stops growing once\n+ * the bus reaches a steady state.\n+ *\n  * To workaround this problem, check for empty FIFO with\n  * rkcanfd_fifo_header_empty() in rkcanfd_handle_rx_int_one() and exit\n  * early.\n@@ -344,6 +350,8 @@\n /* Erratum 6: The CAN controller's transmission of extended frames may\n  * intermittently change into standard frames\n  *\n+ * Tests on the rk3588 show the same problem.\n+ *\n  * Work around this issue by activating self reception (RXSTX). If we\n  * have pending TX CAN frames, check all RX'ed CAN frames in\n  * rkcanfd_rxstx_filter().\n@@ -424,6 +432,9 @@\n  *     cansequence -rv -i 1\n  *\n  * - TX starvation after repeated Bus-Off\n+ *   Tests on the rk3588 show the same problem. In a\n+ *   10-cycle Bus-Off recovery test, 9 cycles failed to send after the\n+ *   controller restarted.\n  *   To reproduce:\n  *   host:\n  *     sleep 3 \u0026\u0026 cangen can0 -I2 -Li -Di -p10 -g 0.0\n@@ -434,6 +445,7 @@\n enum rkcanfd_model {\n \tRKCANFD_MODEL_RK3568V2 = 0x35682,\n \tRKCANFD_MODEL_RK3568V3 = 0x35683,\n+\tRKCANFD_MODEL_RK3588 = 0x3588,\n };\n \n struct rkcanfd_devtype_data {\ndiff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c\nindex 82508a8650959..3b9b2f104d868 100644\n--- a/drivers/net/can/usb/gs_usb.c\n+++ b/drivers/net/can/usb/gs_usb.c\n@@ -1565,7 +1565,7 @@ static int gs_usb_probe(struct usb_interface *intf,\n \n \tif (icount \u003e type_max(parent-\u003echannel_cnt)) {\n \t\tdev_err(\u0026intf-\u003edev,\n-\t\t\t\"Driver cannot handle more that %u CAN interfaces\\n\",\n+\t\t\t\"Driver cannot handle more than %u CAN interfaces\\n\",\n \t\t\ttype_max(parent-\u003echannel_cnt));\n \t\treturn -EINVAL;\n \t}\ndiff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c\nindex e882250180ef6..9e2e25d024717 100644\n--- a/drivers/net/can/vxcan.c\n+++ b/drivers/net/can/vxcan.c\n@@ -33,6 +33,7 @@ MODULE_ALIAS_RTNL_LINK(DRV_NAME);\n \n struct vxcan_priv {\n \tstruct net_device __rcu\t*peer;\n+\tnetdevice_tracker peer_tracker;\n };\n \n static netdev_tx_t vxcan_xmit(struct sk_buff *oskb, struct net_device *dev)\n@@ -268,9 +269,11 @@ static int vxcan_newlink(struct net_device *dev,\n \t/* cross link the device pair */\n \tpriv = netdev_priv(dev);\n \trcu_assign_pointer(priv-\u003epeer, peer);\n+\tnetdev_hold(peer, \u0026priv-\u003epeer_tracker, GFP_KERNEL);\n \n \tpriv = netdev_priv(peer);\n \trcu_assign_pointer(priv-\u003epeer, dev);\n+\tnetdev_hold(dev, \u0026priv-\u003epeer_tracker, GFP_KERNEL);\n \n \treturn 0;\n \n@@ -281,24 +284,25 @@ static int vxcan_newlink(struct net_device *dev,\n \n static void vxcan_dellink(struct net_device *dev, struct list_head *head)\n {\n+\tnetdevice_tracker *peer_tracker;\n \tstruct vxcan_priv *priv;\n \tstruct net_device *peer;\n \n \tpriv = netdev_priv(dev);\n-\tpeer = rtnl_dereference(priv-\u003epeer);\n+\tpeer_tracker = \u0026priv-\u003epeer_tracker;\n+\tpeer = unrcu_pointer(xchg(\u0026priv-\u003epeer, NULL));\n+\tif (!peer)\n+\t\treturn;\n \n-\t/* Note : dellink() is called from default_device_exit_batch(),\n-\t * before a rcu_synchronize() point. The devices are guaranteed\n-\t * not being freed before one RCU grace period.\n-\t */\n-\tRCU_INIT_POINTER(priv-\u003epeer, NULL);\n \tunregister_netdevice_queue(dev, head);\n \n-\tif (peer) {\n-\t\tpriv = netdev_priv(peer);\n-\t\tRCU_INIT_POINTER(priv-\u003epeer, NULL);\n-\t\tunregister_netdevice_queue(peer, head);\n-\t}\n+\tpriv = netdev_priv(peer);\n+\tdev = unrcu_pointer(xchg(\u0026priv-\u003epeer, NULL));\n+\tif (dev)\n+\t\tunregister_netdevice_queue_net(dev_net(dev), peer, head);\n+\n+\tnetdev_put(peer, peer_tracker);\n+\tnetdev_put(dev, \u0026priv-\u003epeer_tracker);\n }\n \n static const struct nla_policy vxcan_policy[VXCAN_INFO_MAX + 1] = {\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "CAN",
    "CAN_DEV",
    "CAN_VXCAN"
  ],
  "FocusSymbols": [
    "vxcan_newlink",
    "vxcan_dellink"
  ],
  "Reasoning": "The patch modifies `vxcan_newlink` and `vxcan_dellink` in the virtual CAN tunnel driver (`vxcan`) to use `netdevice_tracker` for peer devices, fixing potential use-after-free or refcounting issues. Since `vxcan` is a virtual network device that can be instantiated via netlink, these changes are easily reachable and should be fuzzed. Other changes in the series are either documentation, typo fixes, or affect hardware-specific drivers (SPI, Rockchip, PCI) not easily emulated.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
  even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. List them in the EnableConfigs
   output array, and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit 3bf9ce15093070312928a5f69561c1a476d7384f
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Aug 17 23:47:05 2026 +0000

    syz-cluster: applied patch under review

diff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
index a077c03300137..81e2b6dfeb023 100644
--- a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
@@ -16,7 +16,9 @@ allOf:
 properties:
   compatible:
     oneOf:
-      - const: rockchip,rk3568v2-canfd
+      - enum:
+          - rockchip,rk3568v2-canfd
+          - rockchip,rk3588-canfd
       - items:
           - const: rockchip,rk3568v3-canfd
           - const: rockchip,rk3568v2-canfd
diff --git a/Documentation/devicetree/bindings/net/can/ti,am3517-hecc.yaml b/Documentation/devicetree/bindings/net/can/ti,am3517-hecc.yaml
new file mode 100644
index 0000000000000..7874e9e492244
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ti,am3517-hecc.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/can/ti,am3517-hecc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments High End CAN Controller (HECC)
+
+maintainers:
+  - Eduard Bostina <egbostina@gmail.com>
+
+allOf:
+  - $ref: can-controller.yaml#
+
+properties:
+  compatible:
+    const: ti,am3517-hecc
+
+  reg:
+    maxItems: 3
+
+  reg-names:
+    items:
+      - const: hecc
+      - const: hecc-ram
+      - const: mbx
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  ti,use-hecc1int:
+    type: boolean
+    description:
+      If provided, configures HECC to produce all interrupts on the
+      HECC1INT interrupt line. By default, the HECC0INT interrupt line
+      will be used.
+    default: false
+
+  xceiver-supply:
+    description: Regulator that powers the CAN transceiver.
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - interrupts
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    can@5c050000 {
+        compatible = "ti,am3517-hecc";
+        reg = <0x5c050000 0x80>,
+              <0x5c053000 0x180>,
+              <0x5c052000 0x200>;
+        reg-names = "hecc", "hecc-ram", "mbx";
+        interrupts = <24>;
+        clocks = <&hecc_ck>;
+    };
diff --git a/Documentation/devicetree/bindings/net/can/ti_hecc.txt b/Documentation/devicetree/bindings/net/can/ti_hecc.txt
deleted file mode 100644
index e0f0a7cfe3293..0000000000000
--- a/Documentation/devicetree/bindings/net/can/ti_hecc.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Texas Instruments High End CAN Controller (HECC)
-================================================
-
-This file provides information, what the device node
-for the hecc interface contains.
-
-Required properties:
-- compatible: "ti,am3517-hecc"
-- reg: addresses and lengths of the register spaces for 'hecc', 'hecc-ram'
-       and 'mbx'
-- reg-names :"hecc", "hecc-ram", "mbx"
-- interrupts: interrupt mapping for the hecc interrupts sources
-- clocks: clock phandles (see clock bindings for details)
-
-Optional properties:
-- ti,use-hecc1int: if provided configures HECC to produce all interrupts
-		   on HECC1INT interrupt line. By default HECC0INT interrupt
-		   line will be used.
-- xceiver-supply: regulator that powers the CAN transceiver
-
-Example:
-
-For am3517evm board:
-	hecc: can@5c050000 {
-		compatible = "ti,am3517-hecc";
-		reg = <0x5c050000 0x80>,
-		      <0x5c053000 0x180>,
-		      <0x5c052000 0x200>;
-		reg-names = "hecc", "hecc-ram", "mbx";
-		interrupts = <24>;
-		clocks = <&hecc_ck>;
-	};
diff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
index 40835497050a5..18015e60fd6d6 100644
--- a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
+++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
@@ -8,7 +8,7 @@ title:
   Xilinx CAN and CANFD controller
 
 maintainers:
-  - Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
+  - Harini T <harini.t@amd.com>
 
 properties:
   compatible:
@@ -53,6 +53,9 @@ properties:
     $ref: /schemas/types.yaml#/definitions/flag
     description: CAN TX_OL, TX_TL and RX FIFOs have ECC support(AXI CAN)
 
+  phys:
+    maxItems: 1
+
 required:
   - compatible
   - reg
diff --git a/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg b/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg
index 381323423b4ca..c8cf0bc49b69a 100644
--- a/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg
+++ b/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg
@@ -93,9 +93,9 @@
    <ellipse cx="144.827" cy="159.143" rx="10.8866" ry="4.39308"/>
    <ellipse cx="59.4364" cy="142.823" rx="7.36455" ry="4.39308"/>
    <ellipse cx="144.827" cy="129.196" rx="10.8866" ry="4.39308"/>
-   <ellipse cx="143.077" cy="180.53" rx="10.8866" ry="4.39308"/>
   </g>
-  <ellipse cx="110.386" cy="180.53" rx="10.8866" ry="4.39308" fill="#ffcb35" stroke="#000" stroke-linecap="square" stroke-width=".499999"/>
+  <ellipse cx="110.386" cy="180.53" rx="10.8866" ry="4.39308" fill="#28a4ff" stroke="#000" stroke-linecap="square" stroke-width=".499999"/>
+  <ellipse cx="143.077" cy="180.53" rx="10.8866" ry="4.39308" fill="#ffcb35" stroke="#000" stroke-linecap="square" stroke-width=".499999"/>
   <text x="110.90907" y="179.42688" font-size="3.175px" xml:space="preserve"><tspan x="110.90907" y="179.42688" dy="0.60000002" text-align="center" text-anchor="middle">Accessible</tspan><tspan x="110.90907" y="183.39563"><tspan font-size="3.175px" text-align="center" text-anchor="middle">for S</tspan>W</tspan></text>
   <text x="143.5869" y="179.52795" xml:space="preserve"><tspan x="143.5869" y="179.52795" dy="1 0 0 0 0 0" font-family="sans-serif" font-size="2.82222px" text-align="center" text-anchor="middle" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">Inaccessible</tspan><tspan x="143.5869" y="183.36786" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">for S</tspan>W</tspan></text>
   <g font-size="3.175px">
diff --git a/MAINTAINERS b/MAINTAINERS
index 991460050da74..6b49a2c80cd5d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29573,7 +29573,7 @@ F:	Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml
 F:	drivers/net/ethernet/xilinx/xilinx_axienet*
 
 XILINX CAN DRIVER
-M:	Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
+M:	Harini T <harini.t@amd.com>
 L:	linux-can@vger.kernel.org
 S:	Maintained
 F:	Documentation/devicetree/bindings/net/can/xilinx,can.yaml
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index eb856547ae7df..16f80607e150e 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -2464,7 +2464,7 @@ struct m_can_classdev *m_can_class_allocate_dev(struct device *dev,
 		return ERR_PTR(ret);
 	}
 
-	if (dev->of_node && of_property_read_bool(dev->of_node, "wakeup-source"))
+	if (dev->of_node && of_property_present(dev->of_node, "wakeup-source"))
 		device_set_wakeup_capable(dev, true);
 
 	/* Get TX FIFO size
diff --git a/drivers/net/can/m_can/m_can_pci.c b/drivers/net/can/m_can/m_can_pci.c
index eb31ed1f96449..d11a7c88fc32f 100644
--- a/drivers/net/can/m_can/m_can_pci.c
+++ b/drivers/net/can/m_can/m_can_pci.c
@@ -126,7 +126,7 @@ static int m_can_pci_probe(struct pci_dev *pci, const struct pci_device_id *id)
 	mcan_class->net->irq = pci_irq_vector(pci, 0);
 	mcan_class->pm_clock_support = 1;
 	mcan_class->pm_wake_source = 0;
-	mcan_class->can.clock.freq = id->driver_data;
+	mcan_class->can.clock.freq = M_CAN_CLOCK_FREQ_EHL;
 	mcan_class->irq_edge_triggered = true;
 	mcan_class->ops = &m_can_pci_ops;
 
@@ -183,8 +183,8 @@ static SIMPLE_DEV_PM_OPS(m_can_pci_pm_ops,
 			 m_can_pci_suspend, m_can_pci_resume);
 
 static const struct pci_device_id m_can_pci_id_table[] = {
-	{ PCI_VDEVICE(INTEL, 0x4bc1), M_CAN_CLOCK_FREQ_EHL, },
-	{ PCI_VDEVICE(INTEL, 0x4bc2), M_CAN_CLOCK_FREQ_EHL, },
+	{ PCI_VDEVICE(INTEL, 0x4bc1) },
+	{ PCI_VDEVICE(INTEL, 0x4bc2) },
 	{  }	/* Terminating Entry */
 };
 MODULE_DEVICE_TABLE(pci, m_can_pci_id_table);
diff --git a/drivers/net/can/m_can/tcan4x5x-core.c b/drivers/net/can/m_can/tcan4x5x-core.c
index 31cc9d0abd453..a5b8829aa5193 100644
--- a/drivers/net/can/m_can/tcan4x5x-core.c
+++ b/drivers/net/can/m_can/tcan4x5x-core.c
@@ -211,8 +211,31 @@ static int tcan4x5x_write_fifo(struct m_can_classdev *cdev,
 	return regmap_bulk_write(priv->regmap, TCAN4X5X_MRAM_START + addr_offset, val, val_count);
 }
 
-static int tcan4x5x_power_enable(struct regulator *reg, int enable)
+static int tcan4x5x_power_enable(struct tcan4x5x_priv *priv, int enable)
 {
+	struct regulator *reg = priv->power;
+
+	/*
+	 * Put the device into sleep mode if the RST pin is available,
+	 * since a wake-up event, RST pin toggle, or power cycle are the only
+	 * ways to exit sleep mode.
+	 * Redundant if the regulator is exclusive to this device, but that
+	 * can't be determined here.
+	 *
+	 * Datasheet: TCAN4550, section "8.4.3 Sleep Mode"
+	 * https://www.ti.com/lit/gpn/tcan4550
+	 */
+	if (priv->reset_gpio && !enable) {
+		int ret;
+
+		ret = regmap_update_bits(priv->regmap, TCAN4X5X_CONFIG,
+					 TCAN4X5X_MODE_SEL_MASK,
+					 TCAN4X5X_MODE_SLEEP);
+		if (ret)
+			dev_err(&priv->spi->dev, "Setting sleep mode failed %pe\n",
+				ERR_PTR(ret));
+	}
+
 	if (IS_ERR_OR_NULL(reg))
 		return 0;
 
@@ -476,7 +499,7 @@ static int tcan4x5x_can_probe(struct spi_device *spi)
 		goto out_m_can_class_free_dev;
 	}
 
-	ret = tcan4x5x_power_enable(priv->power, 1);
+	ret = tcan4x5x_power_enable(priv, 1);
 	if (ret) {
 		dev_err(&spi->dev, "Enabling regulator failed %pe\n",
 			ERR_PTR(ret));
@@ -531,7 +554,7 @@ static int tcan4x5x_can_probe(struct spi_device *spi)
 	return 0;
 
 out_power:
-	tcan4x5x_power_enable(priv->power, 0);
+	tcan4x5x_power_enable(priv, 0);
  out_m_can_class_free_dev:
 	m_can_class_free_dev(mcan_class->net);
 	return ret;
@@ -543,7 +566,7 @@ static void tcan4x5x_can_remove(struct spi_device *spi)
 
 	m_can_class_unregister(&priv->cdev);
 
-	tcan4x5x_power_enable(priv->power, 0);
+	tcan4x5x_power_enable(priv, 0);
 
 	m_can_class_free_dev(priv->cdev.net);
 }
diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 29de0c01e4edc..37c1c22c40c9f 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -50,6 +50,12 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
 		RKCANFD_QUIRK_CANFD_BROKEN,
 };
 
+static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3588 = {
+	.model = RKCANFD_MODEL_RK3588,
+	.quirks = RKCANFD_QUIRK_RK3568_ERRATUM_5 |
+		RKCANFD_QUIRK_RK3568_ERRATUM_6,
+};
+
 static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
 {
 	switch (model) {
@@ -57,6 +63,8 @@ static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
 		return "rk3568v2";
 	case RKCANFD_MODEL_RK3568V3:
 		return "rk3568v3";
+	case RKCANFD_MODEL_RK3588:
+		return "rk3588";
 	}
 
 	return "<unknown>";
@@ -148,6 +156,12 @@ static int rkcanfd_set_bittiming(struct rkcanfd_priv *priv)
 
 	rkcanfd_write(priv, RKCANFD_REG_FD_DATA_BITTIMING, reg_dbt);
 
+	/* RK3588 CAN-FD BRS works with TDC disabled. */
+	if (priv->devtype_data.model == RKCANFD_MODEL_RK3588) {
+		rkcanfd_write(priv, RKCANFD_REG_TRANSMIT_DELAY_COMPENSATION, 0);
+		return 0;
+	}
+
 	tdco = (priv->can.clock.freq / dbt->bitrate) * 2 / 3;
 	tdco = min(tdco, FIELD_MAX(RKCANFD_REG_TRANSMIT_DELAY_COMPENSATION_TDC_OFFSET));
 
@@ -846,6 +860,9 @@ static const struct of_device_id rkcanfd_of_match[] = {
 	}, {
 		.compatible = "rockchip,rk3568v3-canfd",
 		.data = &rkcanfd_devtype_data_rk3568v3,
+	}, {
+		.compatible = "rockchip,rk3588-canfd",
+		.data = &rkcanfd_devtype_data_rk3588,
 	}, {
 		/* sentinel */
 	},
diff --git a/drivers/net/can/rockchip/rockchip_canfd-rx.c b/drivers/net/can/rockchip/rockchip_canfd-rx.c
index 475c0409e215a..24e87daa1df00 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-rx.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-rx.c
@@ -281,7 +281,10 @@ rkcanfd_rx_fifo_get_len(const struct rkcanfd_priv *priv)
 {
 	const u32 reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);
 
-	return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT, reg);
+	if (priv->devtype_data.model == RKCANFD_MODEL_RK3588)
+		return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588, reg);
+
+	return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568, reg);
 }
 
 int rkcanfd_handle_rx_int(struct rkcanfd_priv *priv)
diff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h
index 93131c7d7f54d..95bea9bfd8a2f 100644
--- a/drivers/net/can/rockchip/rockchip_canfd.h
+++ b/drivers/net/can/rockchip/rockchip_canfd.h
@@ -214,7 +214,8 @@
 #define RKCANFD_REG_TXEVENT_FIFO_CTRL_TXE_FIFO_ENABLE BIT(0)
 
 #define RKCANFD_REG_RX_FIFO_CTRL 0x118
-#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT GENMASK(6, 4)
+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568 GENMASK(6, 4)
+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588 GENMASK(7, 5)
 #define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_FULL_WATERMARK GENMASK(3, 1)
 #define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_ENABLE BIT(0)
 
@@ -331,6 +332,11 @@
  * rarely with the standard clock of 300 MHz, but almost immediately
  * at 80 MHz.
  *
+ * Tests on the rk3588 show the same empty FIFO condition.
+ * In that setup rx_fifo_empty_errors increments when the bus
+ * transitions from idle to high CAN-FD load and stops growing once
+ * the bus reaches a steady state.
+ *
  * To workaround this problem, check for empty FIFO with
  * rkcanfd_fifo_header_empty() in rkcanfd_handle_rx_int_one() and exit
  * early.
@@ -344,6 +350,8 @@
 /* Erratum 6: The CAN controller's transmission of extended frames may
  * intermittently change into standard frames
  *
+ * Tests on the rk3588 show the same problem.
+ *
  * Work around this issue by activating self reception (RXSTX). If we
  * have pending TX CAN frames, check all RX'ed CAN frames in
  * rkcanfd_rxstx_filter().
@@ -424,6 +432,9 @@
  *     cansequence -rv -i 1
  *
  * - TX starvation after repeated Bus-Off
+ *   Tests on the rk3588 show the same problem. In a
+ *   10-cycle Bus-Off recovery test, 9 cycles failed to send after the
+ *   controller restarted.
  *   To reproduce:
  *   host:
  *     sleep 3 && cangen can0 -I2 -Li -Di -p10 -g 0.0
@@ -434,6 +445,7 @@
 enum rkcanfd_model {
 	RKCANFD_MODEL_RK3568V2 = 0x35682,
 	RKCANFD_MODEL_RK3568V3 = 0x35683,
+	RKCANFD_MODEL_RK3588 = 0x3588,
 };
 
 struct rkcanfd_devtype_data {
diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
index 82508a8650959..3b9b2f104d868 100644
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -1565,7 +1565,7 @@ static int gs_usb_probe(struct usb_interface *intf,
 
 	if (icount > type_max(parent->channel_cnt)) {
 		dev_err(&intf->dev,
-			"Driver cannot handle more that %u CAN interfaces\n",
+			"Driver cannot handle more than %u CAN interfaces\n",
 			type_max(parent->channel_cnt));
 		return -EINVAL;
 	}
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index e882250180ef6..9e2e25d024717 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -33,6 +33,7 @@ MODULE_ALIAS_RTNL_LINK(DRV_NAME);
 
 struct vxcan_priv {
 	struct net_device __rcu	*peer;
+	netdevice_tracker peer_tracker;
 };
 
 static netdev_tx_t vxcan_xmit(struct sk_buff *oskb, struct net_device *dev)
@@ -268,9 +269,11 @@ static int vxcan_newlink(struct net_device *dev,
 	/* cross link the device pair */
 	priv = netdev_priv(dev);
 	rcu_assign_pointer(priv->peer, peer);
+	netdev_hold(peer, &priv->peer_tracker, GFP_KERNEL);
 
 	priv = netdev_priv(peer);
 	rcu_assign_pointer(priv->peer, dev);
+	netdev_hold(dev, &priv->peer_tracker, GFP_KERNEL);
 
 	return 0;
 
@@ -281,24 +284,25 @@ static int vxcan_newlink(struct net_device *dev,
 
 static void vxcan_dellink(struct net_device *dev, struct list_head *head)
 {
+	netdevice_tracker *peer_tracker;
 	struct vxcan_priv *priv;
 	struct net_device *peer;
 
 	priv = netdev_priv(dev);
-	peer = rtnl_dereference(priv->peer);
+	peer_tracker = &priv->peer_tracker;
+	peer = unrcu_pointer(xchg(&priv->peer, NULL));
+	if (!peer)
+		return;
 
-	/* Note : dellink() is called from default_device_exit_batch(),
-	 * before a rcu_synchronize() point. The devices are guaranteed
-	 * not being freed before one RCU grace period.
-	 */
-	RCU_INIT_POINTER(priv->peer, NULL);
 	unregister_netdevice_queue(dev, head);
 
-	if (peer) {
-		priv = netdev_priv(peer);
-		RCU_INIT_POINTER(priv->peer, NULL);
-		unregister_netdevice_queue(peer, head);
-	}
+	priv = netdev_priv(peer);
+	dev = unrcu_pointer(xchg(&priv->peer, NULL));
+	if (dev)
+		unregister_netdevice_queue_net(dev_net(dev), peer, head);
+
+	netdev_put(peer, peer_tracker);
+	netdev_put(dev, &priv->peer_tracker);
 }
 
 static const struct nla_policy vxcan_policy[VXCAN_INFO_MAX + 1] = {

gemini-3.1-pro-preview

null

null

							input: 9501
							output: 19
							thoughts: 1022
						

**Patch Series Evaluation for Fuzzing Candidate Identification**

Okay, let's break this down. My goal here is to determine which, if any, of these kernel changes warrant focused fuzzing efforts. First, I need to understand if the patchset makes any functional changes to the kernel, and then I need to assess how accessible those changes are for fuzzing.

Looking at the diff, it's pretty clear that the bulk of the changes are documentation updates – not interesting from a fuzzing perspective, so those are out. The `MAINTAINERS` file change is irrelevant.

Now, let's dig into the driver changes. I see a minor API change in `drivers/net/can/m_can/m_can.c` where `of_property_read_bool` is replaced with `of_property_present`. It's a subtle change, as `of_property_read_bool` implicitly checks if the property exists, therefore, no fuzzing required.  Similarly, the refactoring in `drivers/net/can/m_can/m_can_pci.c` seems like cleanup with no functional changes.

Next, `drivers/net/can/m_can/tcan4x5x-core.c` has a functional change in the teardown/suspend/probe error path. It's putting the device to sleep. Hmm, this is an SPI CAN controller. I'm going to guess this isn't easy to reach with standard QEMU; getting SPI devices right in QEMU can be a pain. I should note this down, but it's probably low priority.

The changes in `drivers/net/can/rockchip/rockchip_canfd-core.c`, `rockchip_canfd-rx.c`, and `rockchip_canfd.h` add support for the `rk3588`. It's a platform driver, so again, reaching this through standard QEMU is unlikely, unless a specific machine configuration is setup.

A typo fix in `drivers/net/can/usb/gs_usb.c` is…well, it's a typo fix.

Now, here's where it gets interesting: `drivers/net/can/vxcan.c`. We've got changes to `vxcan_newlink` and `vxcan_dellink`. I see they're introducing `netdevice_tracker` and using `netdev_hold` and `netdev_put`. This is a *functional change* in `vxcan`, which is a virtual CAN tunnel. Crucially, I know that `vxcan` is a virtual network device, much like `veth`, and thus easily reachable via netlink (rtnetlink) in QEMU/syzkaller. Bingo! This is definitely worth fuzzing and should be top priority. I need to take a closer look at these `vxcan` changes in particular.

{
  "Expression": "vxcan_newlink"
}

{
  "Output": "drivers/net/can/vxcan.c=202=static struct rtnl_link_ops vxcan_link_ops;\ndrivers/net/can/vxcan.c-203-\ndrivers/net/can/vxcan.c:204:static int vxcan_newlink(struct net_device *dev,\ndrivers/net/can/vxcan.c-205-\t\t\t struct rtnl_newlink_params *params,\n--\ndrivers/net/can/vxcan.c=320=static struct rtnl_link_ops vxcan_link_ops = {\n--\ndrivers/net/can/vxcan.c-323-\t.setup\t\t= vxcan_setup,\ndrivers/net/can/vxcan.c:324:\t.newlink\t= vxcan_newlink,\ndrivers/net/can/vxcan.c-325-\t.dellink\t= vxcan_dellink,\n"
}

gemini-3.1-pro-preview

null

null

							input: 11406
							output: 19
							thoughts: 52
						

**My Assessment of the vxcan.c Modifications**

Okay, so the modifications to `vxcan.c` are focused on two key functions: `vxcan_newlink` and `vxcan_dellink`. These are the creation and deletion of virtual CAN interfaces, respectively. That immediately tells me this is likely the core of the new functionality. From an architecture perspective, these are critical points, and definitely *reachable* and *testable*. I'll need to scrutinize how they handle error conditions, resource allocation and deallocation, and interaction with the CAN core.

Next, I need to check the build configuration. I'm going to look at the `Kconfig` file. Specifically, I'll search for the `vxcan` option. Is this a new feature gated behind a config option? Is it included by default? Understanding the build system integration is key to understanding how this new functionality is intended to be used and, of course, how it can be tested in different scenarios and configurations. A quick check of `Kconfig` will tell me if I need to worry about conditional compilation or not.

{
  "Expression": "config CAN_VXCAN"
}

{
  "Output": "drivers/net/can/Kconfig=25=config CAN_VCAN\n--\ndrivers/net/can/Kconfig-33-\ndrivers/net/can/Kconfig:34:config CAN_VXCAN\ndrivers/net/can/Kconfig-35-\ttristate \"Virtual CAN Tunnel (vxcan)\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 11797
							output: 35
							thoughts: 21
						

Here's my summary, as if I were thinking these thoughts:

**Analyzing the CAN_VXCAN Kconfig Entry**

Okay, let's dive into the `drivers/net/can/Kconfig` file, specifically the section related to `CAN_VXCAN`. I need to get a clear picture of how this virtual CAN device is configured and what dependencies it has. First, I’ll want to understand the dependencies. Is it dependent on other CAN drivers, or some underlying network configuration? Are there any specific hardware features it requires, even if it's virtual? It's all about how `CAN_VXCAN` fits into the broader CAN ecosystem within this kernel. I want to see how the build system will resolve this to a working configuration, and understand what I would need to do to enable it. I need a clear understanding of what will enable `CAN_VXCAN`. Are there other settings that will also be needed? What kind of system will have a good application for the use of `CAN_VXCAN`? I'll probably look for its help text and see what it tells me.

{
  "File": "drivers/net/can/Kconfig",
  "FirstLine": 30,
  "LineCount": 20
}

{
  "Contents": "  30:\t\n  31:\t\t  This driver can also be built as a module.  If so, the module\n  32:\t\t  will be called vcan.\n  33:\t\n  34:\tconfig CAN_VXCAN\n  35:\t\ttristate \"Virtual CAN Tunnel (vxcan)\"\n  36:\t\thelp\n  37:\t\t  Similar to the virtual ethernet driver veth, vxcan implements a\n  38:\t\t  local CAN traffic tunnel between two virtual CAN network devices.\n  39:\t\t  When creating a vxcan, two vxcan devices are created as pair.\n  40:\t\t  When one end receives the packet it appears on its pair and vice\n  41:\t\t  versa. The vxcan can be used for cross namespace communication.\n  42:\t\n  43:\t\t  To have a clean start in each namespace the CAN GW hop counter is\n  44:\t\t  set to zero.\n  45:\t\n  46:\t\t  This driver can also be built as a module.  If so, the module\n  47:\t\t  will be called vxcan.\n  48:\t\n  49:\tconfig CAN_NETLINK\n"
}

gemini-3.1-pro-preview

null

null

							input: 12378
							output: 34
							thoughts: 24
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Analyzing CAN Driver Configuration Dependencies**

Okay, so the implementation strategy hinges on the conditional availability of something. I need to figure out the enabling condition for this. My first instinct is to immediately check the Kconfig file for the CAN drivers. This is the central repository for build configuration logic within the kernel's CAN subsystem. So, let's head to `drivers/net/can/Kconfig` and dive right into that file. I'm expecting to find a clear dependency declaration, possibly an `if` statement, defining the condition I'm looking for. Let's see if it's there.

{
  "File": "drivers/net/can/Kconfig",
  "FirstLine": 1,
  "LineCount": 20
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0-only\n   2:\t\n   3:\tmenuconfig CAN_DEV\n   4:\t\ttristate \"CAN Device Drivers\"\n   5:\t\tdefault y\n   6:\t\tdepends on CAN\n   7:\t\thelp\n   8:\t\t  Controller Area Network (CAN) is serial communications protocol up to\n   9:\t\t  1Mbit/s for its original release (now known as Classical CAN) and up\n  10:\t\t  to 8Mbit/s for the more recent CAN with Flexible Data-Rate\n  11:\t\t  (CAN-FD). The CAN bus was originally mainly for automotive, but is now\n  12:\t\t  widely used in marine (NMEA2000), industrial, and medical\n  13:\t\t  applications. More information on the CAN network protocol family\n  14:\t\t  PF_CAN is contained in \u003cDocumentation/networking/can.rst\u003e.\n  15:\t\n  16:\t\t  This section contains all the CAN(-FD) device drivers including the\n  17:\t\t  virtual ones. If you own such devices or plan to use the virtual CAN\n  18:\t\t  interfaces to develop applications, say Y here.\n  19:\t\n  20:\t\t  To compile as a module, choose M here: the module will be called\n"
}

gemini-3.1-pro-preview

null

null

							input: 12908
							output: 32
							thoughts: 34
						

Okay, here's my interpretation of those thoughts, summarized from my perspective as someone familiar with kernel configuration:

**Kernel Configuration Dependencies**

Alright, so I'm diving into this `CAN_VXCAN` module and, as I suspected, it needs both `CAN` and `CAN_DEV` enabled. That's pretty standard for these virtual CAN devices; they're built on the foundational CAN infrastructure.

My next step is to quickly cross-reference that in the `net/can/Kconfig` file. I'll need to check the Kconfig file for `CAN` to refresh my memory on any relevant dependencies or configuration options that I might need to consider. It's always good to make sure I understand the full scope of what's required for `CAN_VXCAN` to function correctly.

{
  "File": "net/can/Kconfig",
  "FirstLine": 1,
  "LineCount": 20
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0-only\n   2:\t#\n   3:\t# Controller Area Network (CAN) network layer core configuration\n   4:\t#\n   5:\t\n   6:\tmenuconfig CAN\n   7:\t\ttristate \"CAN bus subsystem support\"\n   8:\t\tselect SKB_EXTENSIONS\n   9:\t\thelp\n  10:\t\t  Controller Area Network (CAN) is a slow (up to 1Mbit/s) serial\n  11:\t\t  communications protocol. Development of the CAN bus started in\n  12:\t\t  1983 at Robert Bosch GmbH, and the protocol was officially\n  13:\t\t  released in 1986. The CAN bus was originally mainly for automotive,\n  14:\t\t  but is now widely used in marine (NMEA2000), industrial, and medical\n  15:\t\t  applications. More information on the CAN network protocol family\n  16:\t\t  PF_CAN is contained in \u003cDocumentation/networking/can.rst\u003e.\n  17:\t\n  18:\t\t  If you want CAN support you should say Y here and also to the\n  19:\t\t  specific driver for your controller(s) under the Network device\n  20:\t\t  support section.\n"
}

gemini-3.1-pro-preview

null

null

							input: 13459
							output: 19
							thoughts: 189
						

**My Initial Assessment of CAN Driver Reachability**

Okay, so I'm looking at these CAN driver options: `CAN`, `CAN_DEV`, `CAN_VXCAN`. My initial thought is to quickly assess what's easily testable. What about the specifics, like `tcan4x5x-core.c`? That's an SPI driver, the `TCAN4X5X` – potentially a hurdle. Then there's `rockchip_canfd-core.c`, probably for the `CAN_ROCKCHIP_CANFD` platform. And `m_can` is simply `CAN_M_CAN`. These are all hardware-specific drivers; they're going to be a bit trickier to get my hands on directly for testing or analysis.

However, `vxcan`, being a virtual driver, immediately stands out as the most reachable and testable candidate. That's the key. I can work with that.

Now, my focus shifts. I need to zero in on the core functionalities of `vxcan.c` to understand the entry points. So, I'll check its functions, specifically looking at `vxcan_newlink` and `vxcan_dellink`. These are the ones I need to examine for interaction with the CAN network. Time to double-check their signatures, make sure I understand how they function.

{
  "Expression": "vxcan_newlink"
}

{
  "Output": "drivers/net/can/vxcan.c=202=static struct rtnl_link_ops vxcan_link_ops;\ndrivers/net/can/vxcan.c-203-\ndrivers/net/can/vxcan.c:204:static int vxcan_newlink(struct net_device *dev,\ndrivers/net/can/vxcan.c-205-\t\t\t struct rtnl_newlink_params *params,\n--\ndrivers/net/can/vxcan.c=320=static struct rtnl_link_ops vxcan_link_ops = {\n--\ndrivers/net/can/vxcan.c-323-\t.setup\t\t= vxcan_setup,\ndrivers/net/can/vxcan.c:324:\t.newlink\t= vxcan_newlink,\ndrivers/net/can/vxcan.c-325-\t.dellink\t= vxcan_dellink,\n"
}

gemini-3.1-pro-preview

null

null

							input: 14193
							output: 19
							thoughts: 11
						

Okay, here's my attempt at summarizing that thought process, keeping in mind I'm speaking to a fellow expert:

**Investigating `vxcan_dellink`**

Alright, time to dive in. My mind immediately goes to `vxcan_dellink`. I need to assess what's happening with that particular function or component. I'm probably thinking about a specific problem or perhaps I'm investigating an error report. First, I need to see what I know, and what I *don't* know, about how `vxcan_dellink` is behaving right now. Is it performing as expected? Are there any reported anomalies? Based on that, I'll start checking the code directly, maybe look for related log entries, or begin tracing the function's execution to see where the bottleneck might be, or maybe to see if I can find an unexpected condition that's causing the issue. This is likely the crucial step. Let’s get to work.

{
  "Expression": "vxcan_dellink"
}

{
  "Output": "drivers/net/can/vxcan.c=204=static int vxcan_newlink(struct net_device *dev,\n--\ndrivers/net/can/vxcan.c-284-\ndrivers/net/can/vxcan.c:285:static void vxcan_dellink(struct net_device *dev, struct list_head *head)\ndrivers/net/can/vxcan.c-286-{\n--\ndrivers/net/can/vxcan.c=320=static struct rtnl_link_ops vxcan_link_ops = {\n--\ndrivers/net/can/vxcan.c-324-\t.newlink\t= vxcan_newlink,\ndrivers/net/can/vxcan.c:325:\t.dellink\t= vxcan_dellink,\ndrivers/net/can/vxcan.c-326-\t.policy\t\t= vxcan_policy,\n"
}

gemini-3.1-pro-preview

null

null

							input: 14662
							output: 175
							thoughts: 462
						

**My Assessment of the CAN Driver Patch**

Okay, after reviewing this patch series, I've zeroed in on the core of the matter. It looks like the most impactful changes, and therefore the ones I need to focus on for fuzzing, are definitely in `vxcan.c`. Specifically, the modifications to `vxcan_newlink` and `vxcan_dellink` are where the real juice is. From what I can tell, they’ve addressed a potential use-after-free or refcounting issue by introducing `netdevice_tracker` and using `netdev_hold`/`netdev_put`. Smart move, that’s exactly the kind of thing that can bite you later if you're not careful.

I took a look through the other files touched in the patch, of course. The typo in `gs_usb.c`? Not worth the time, and the `of_property` change in `m_can.c` and the refactoring in `m_can_pci.c` seem more cosmetic or related to device initialization/configuration, nothing that would be a high priority for fuzzing. `tcan4x5x-core.c` and `rockchip_canfd-core.c` are SPI and platform device drivers respectively, which aren't easily reachable in my standard QEMU setup, so I'm writing those off for now.

So, it's clear: `vxcan.c` is the target. The virtual CAN tunnel driver, `vxcan`, is easily reachable through netlink, which makes it a prime candidate for fuzzing. The fact that they are fixing this kind of potential memory issue is also a good reason to focus on it.

Therefore, my summary and recommendations are:

*   **WorthFuzzing**: true
*   **FocusSymbols**:
    *   `vxcan_newlink`
    *   `vxcan_dellink`
*   **EnableConfigs**:
    *   `CAN`
    *   `CAN_DEV`
    *   `CAN_VXCAN`

The patch is touching core ref counting logic on a virtual device, so it is high value and easy to trigger. We're good to go.

{
  "EnableConfigs": [
    "CAN",
    "CAN_DEV",
    "CAN_VXCAN"
  ],
  "FocusSymbols": [
    "vxcan_newlink",
    "vxcan_dellink"
  ],
  "Reasoning": "The patch modifies `vxcan_newlink` and `vxcan_dellink` in the virtual CAN tunnel driver (`vxcan`) to use `netdevice_tracker` for peer devices, fixing potential use-after-free or refcounting issues. Since `vxcan` is a virtual network device that can be instantiated via netlink, these changes are easily reachable and should be fuzzed. Other changes in the series are either documentation, typo fixes, or affect hardware-specific drivers (SPI, Rockchip, PCI) not easily emulated.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "CAN",
    "CAN_DEV",
    "CAN_VXCAN"
  ],
  "FocusSymbols": [
    "vxcan_newlink",
    "vxcan_dellink"
  ],
  "Reasoning": "The patch modifies `vxcan_newlink` and `vxcan_dellink` in the virtual CAN tunnel driver (`vxcan`) to use `netdevice_tracker` for peer devices, fixing potential use-after-free or refcounting issues. Since `vxcan` is a virtual network device that can be instantiated via netlink, these changes are easily reachable and should be fuzzed. Other changes in the series are either documentation, typo fixes, or affect hardware-specific drivers (SPI, Rockchip, PCI) not easily emulated.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "The patch series consists of device tree binding updates, hardware driver fixes (sleep mode handling in tcan4x5x, RK3588 support in rockchip_canfd, clock frequency in m_can_pci), and a refcounting/UAF fix in vxcan.c using netdevice_tracker. None of these changes introduce new data structures sent to userspace, modify bounds checking in a way that exposes uninitialized memory, or involve complex uninitialized state. The vxcan.c fix addresses a use-after-free/refcounting issue which is effectively caught by standard KASAN. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

You are an expert Linux kernel security engineer specializing in kernel memory
error detectors (KASAN and KMSAN). Your job is to review the provided patch series and
determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer)
fuzzing session in addition to standard KASAN fuzzing.

CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN:
- Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable
  a comprehensive suite of debugging tools and sanitizers, including KASAN
  (out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP
  (locking bugs and deadlocks), UB-sanitizers, and memory corruption checks.
- KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap,
  or page allocations) and kernel-to-user memory info-leaks.

Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN,
LOCKDEP, OR OTHER STANDARD BUG DETECTORS.
A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY
set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks
that are detected ONLY by KMSAN.

Look holistically at the patch series and surrounding code. Even if no direct
uninitialized field accesses or new buffer allocations are added in the diff itself,
a patch may alter control flow, bounds checking, or data length calculations in ways
that change how the rest of the code operates on existing buffers (e.g. allowing
uninitialized stack/heap memory to be read, copied to user space, or used in control
flow). Do not hesitate to use your code access tools to inspect the surrounding code,
called functions, and callers.

Set NeedsKMSAN=true ONLY IF the patch introduces or modifies:
1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb
   attributes, ioctl output arguments, socket options, or BPF buffers) where fields
   or structure padding might not be fully initialized/zeroed.
2. Conditional logic or branching that depends on potentially uninitialized variables
   or struct fields.
3. Allocation or initialization of complex data structures where uninitialized fields
   could be read later in reachable code paths.
4. Bounds checks, lengths, or logic in a way that allows surrounding code to access
   uninitialized bytes of existing buffers.

Set NeedsKMSAN=false IF:
- The code changes primarily risk out-of-bounds access, array overflows, NULL pointer
  dereferences, locking deadlocks, or use-after-free bugs (these are already caught
  by KASAN, LOCKDEP, or standard bug detectors).
- All stack/heap structures touched or introduced by the patch are fully zeroed
  or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied.
- The patch does not introduce any risk of uninitialized memory usage or info-leaks.

Use your code access tools to inspect the surrounding code if necessary, then provide
detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch.
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit 3bf9ce15093070312928a5f69561c1a476d7384f
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Aug 17 23:47:05 2026 +0000

    syz-cluster: applied patch under review

diff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
index a077c03300137..81e2b6dfeb023 100644
--- a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
@@ -16,7 +16,9 @@ allOf:
 properties:
   compatible:
     oneOf:
-      - const: rockchip,rk3568v2-canfd
+      - enum:
+          - rockchip,rk3568v2-canfd
+          - rockchip,rk3588-canfd
       - items:
           - const: rockchip,rk3568v3-canfd
           - const: rockchip,rk3568v2-canfd
diff --git a/Documentation/devicetree/bindings/net/can/ti,am3517-hecc.yaml b/Documentation/devicetree/bindings/net/can/ti,am3517-hecc.yaml
new file mode 100644
index 0000000000000..7874e9e492244
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ti,am3517-hecc.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/can/ti,am3517-hecc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments High End CAN Controller (HECC)
+
+maintainers:
+  - Eduard Bostina <egbostina@gmail.com>
+
+allOf:
+  - $ref: can-controller.yaml#
+
+properties:
+  compatible:
+    const: ti,am3517-hecc
+
+  reg:
+    maxItems: 3
+
+  reg-names:
+    items:
+      - const: hecc
+      - const: hecc-ram
+      - const: mbx
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  ti,use-hecc1int:
+    type: boolean
+    description:
+      If provided, configures HECC to produce all interrupts on the
+      HECC1INT interrupt line. By default, the HECC0INT interrupt line
+      will be used.
+    default: false
+
+  xceiver-supply:
+    description: Regulator that powers the CAN transceiver.
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - interrupts
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    can@5c050000 {
+        compatible = "ti,am3517-hecc";
+        reg = <0x5c050000 0x80>,
+              <0x5c053000 0x180>,
+              <0x5c052000 0x200>;
+        reg-names = "hecc", "hecc-ram", "mbx";
+        interrupts = <24>;
+        clocks = <&hecc_ck>;
+    };
diff --git a/Documentation/devicetree/bindings/net/can/ti_hecc.txt b/Documentation/devicetree/bindings/net/can/ti_hecc.txt
deleted file mode 100644
index e0f0a7cfe3293..0000000000000
--- a/Documentation/devicetree/bindings/net/can/ti_hecc.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Texas Instruments High End CAN Controller (HECC)
-================================================
-
-This file provides information, what the device node
-for the hecc interface contains.
-
-Required properties:
-- compatible: "ti,am3517-hecc"
-- reg: addresses and lengths of the register spaces for 'hecc', 'hecc-ram'
-       and 'mbx'
-- reg-names :"hecc", "hecc-ram", "mbx"
-- interrupts: interrupt mapping for the hecc interrupts sources
-- clocks: clock phandles (see clock bindings for details)
-
-Optional properties:
-- ti,use-hecc1int: if provided configures HECC to produce all interrupts
-		   on HECC1INT interrupt line. By default HECC0INT interrupt
-		   line will be used.
-- xceiver-supply: regulator that powers the CAN transceiver
-
-Example:
-
-For am3517evm board:
-	hecc: can@5c050000 {
-		compatible = "ti,am3517-hecc";
-		reg = <0x5c050000 0x80>,
-		      <0x5c053000 0x180>,
-		      <0x5c052000 0x200>;
-		reg-names = "hecc", "hecc-ram", "mbx";
-		interrupts = <24>;
-		clocks = <&hecc_ck>;
-	};
diff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
index 40835497050a5..18015e60fd6d6 100644
--- a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
+++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
@@ -8,7 +8,7 @@ title:
   Xilinx CAN and CANFD controller
 
 maintainers:
-  - Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
+  - Harini T <harini.t@amd.com>
 
 properties:
   compatible:
@@ -53,6 +53,9 @@ properties:
     $ref: /schemas/types.yaml#/definitions/flag
     description: CAN TX_OL, TX_TL and RX FIFOs have ECC support(AXI CAN)
 
+  phys:
+    maxItems: 1
+
 required:
   - compatible
   - reg
diff --git a/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg b/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg
index 381323423b4ca..c8cf0bc49b69a 100644
--- a/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg
+++ b/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg
@@ -93,9 +93,9 @@
    <ellipse cx="144.827" cy="159.143" rx="10.8866" ry="4.39308"/>
    <ellipse cx="59.4364" cy="142.823" rx="7.36455" ry="4.39308"/>
    <ellipse cx="144.827" cy="129.196" rx="10.8866" ry="4.39308"/>
-   <ellipse cx="143.077" cy="180.53" rx="10.8866" ry="4.39308"/>
   </g>
-  <ellipse cx="110.386" cy="180.53" rx="10.8866" ry="4.39308" fill="#ffcb35" stroke="#000" stroke-linecap="square" stroke-width=".499999"/>
+  <ellipse cx="110.386" cy="180.53" rx="10.8866" ry="4.39308" fill="#28a4ff" stroke="#000" stroke-linecap="square" stroke-width=".499999"/>
+  <ellipse cx="143.077" cy="180.53" rx="10.8866" ry="4.39308" fill="#ffcb35" stroke="#000" stroke-linecap="square" stroke-width=".499999"/>
   <text x="110.90907" y="179.42688" font-size="3.175px" xml:space="preserve"><tspan x="110.90907" y="179.42688" dy="0.60000002" text-align="center" text-anchor="middle">Accessible</tspan><tspan x="110.90907" y="183.39563"><tspan font-size="3.175px" text-align="center" text-anchor="middle">for S</tspan>W</tspan></text>
   <text x="143.5869" y="179.52795" xml:space="preserve"><tspan x="143.5869" y="179.52795" dy="1 0 0 0 0 0" font-family="sans-serif" font-size="2.82222px" text-align="center" text-anchor="middle" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">Inaccessible</tspan><tspan x="143.5869" y="183.36786" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">for S</tspan>W</tspan></text>
   <g font-size="3.175px">
diff --git a/MAINTAINERS b/MAINTAINERS
index 991460050da74..6b49a2c80cd5d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29573,7 +29573,7 @@ F:	Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml
 F:	drivers/net/ethernet/xilinx/xilinx_axienet*
 
 XILINX CAN DRIVER
-M:	Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
+M:	Harini T <harini.t@amd.com>
 L:	linux-can@vger.kernel.org
 S:	Maintained
 F:	Documentation/devicetree/bindings/net/can/xilinx,can.yaml
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index eb856547ae7df..16f80607e150e 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -2464,7 +2464,7 @@ struct m_can_classdev *m_can_class_allocate_dev(struct device *dev,
 		return ERR_PTR(ret);
 	}
 
-	if (dev->of_node && of_property_read_bool(dev->of_node, "wakeup-source"))
+	if (dev->of_node && of_property_present(dev->of_node, "wakeup-source"))
 		device_set_wakeup_capable(dev, true);
 
 	/* Get TX FIFO size
diff --git a/drivers/net/can/m_can/m_can_pci.c b/drivers/net/can/m_can/m_can_pci.c
index eb31ed1f96449..d11a7c88fc32f 100644
--- a/drivers/net/can/m_can/m_can_pci.c
+++ b/drivers/net/can/m_can/m_can_pci.c
@@ -126,7 +126,7 @@ static int m_can_pci_probe(struct pci_dev *pci, const struct pci_device_id *id)
 	mcan_class->net->irq = pci_irq_vector(pci, 0);
 	mcan_class->pm_clock_support = 1;
 	mcan_class->pm_wake_source = 0;
-	mcan_class->can.clock.freq = id->driver_data;
+	mcan_class->can.clock.freq = M_CAN_CLOCK_FREQ_EHL;
 	mcan_class->irq_edge_triggered = true;
 	mcan_class->ops = &m_can_pci_ops;
 
@@ -183,8 +183,8 @@ static SIMPLE_DEV_PM_OPS(m_can_pci_pm_ops,
 			 m_can_pci_suspend, m_can_pci_resume);
 
 static const struct pci_device_id m_can_pci_id_table[] = {
-	{ PCI_VDEVICE(INTEL, 0x4bc1), M_CAN_CLOCK_FREQ_EHL, },
-	{ PCI_VDEVICE(INTEL, 0x4bc2), M_CAN_CLOCK_FREQ_EHL, },
+	{ PCI_VDEVICE(INTEL, 0x4bc1) },
+	{ PCI_VDEVICE(INTEL, 0x4bc2) },
 	{  }	/* Terminating Entry */
 };
 MODULE_DEVICE_TABLE(pci, m_can_pci_id_table);
diff --git a/drivers/net/can/m_can/tcan4x5x-core.c b/drivers/net/can/m_can/tcan4x5x-core.c
index 31cc9d0abd453..a5b8829aa5193 100644
--- a/drivers/net/can/m_can/tcan4x5x-core.c
+++ b/drivers/net/can/m_can/tcan4x5x-core.c
@@ -211,8 +211,31 @@ static int tcan4x5x_write_fifo(struct m_can_classdev *cdev,
 	return regmap_bulk_write(priv->regmap, TCAN4X5X_MRAM_START + addr_offset, val, val_count);
 }
 
-static int tcan4x5x_power_enable(struct regulator *reg, int enable)
+static int tcan4x5x_power_enable(struct tcan4x5x_priv *priv, int enable)
 {
+	struct regulator *reg = priv->power;
+
+	/*
+	 * Put the device into sleep mode if the RST pin is available,
+	 * since a wake-up event, RST pin toggle, or power cycle are the only
+	 * ways to exit sleep mode.
+	 * Redundant if the regulator is exclusive to this device, but that
+	 * can't be determined here.
+	 *
+	 * Datasheet: TCAN4550, section "8.4.3 Sleep Mode"
+	 * https://www.ti.com/lit/gpn/tcan4550
+	 */
+	if (priv->reset_gpio && !enable) {
+		int ret;
+
+		ret = regmap_update_bits(priv->regmap, TCAN4X5X_CONFIG,
+					 TCAN4X5X_MODE_SEL_MASK,
+					 TCAN4X5X_MODE_SLEEP);
+		if (ret)
+			dev_err(&priv->spi->dev, "Setting sleep mode failed %pe\n",
+				ERR_PTR(ret));
+	}
+
 	if (IS_ERR_OR_NULL(reg))
 		return 0;
 
@@ -476,7 +499,7 @@ static int tcan4x5x_can_probe(struct spi_device *spi)
 		goto out_m_can_class_free_dev;
 	}
 
-	ret = tcan4x5x_power_enable(priv->power, 1);
+	ret = tcan4x5x_power_enable(priv, 1);
 	if (ret) {
 		dev_err(&spi->dev, "Enabling regulator failed %pe\n",
 			ERR_PTR(ret));
@@ -531,7 +554,7 @@ static int tcan4x5x_can_probe(struct spi_device *spi)
 	return 0;
 
 out_power:
-	tcan4x5x_power_enable(priv->power, 0);
+	tcan4x5x_power_enable(priv, 0);
  out_m_can_class_free_dev:
 	m_can_class_free_dev(mcan_class->net);
 	return ret;
@@ -543,7 +566,7 @@ static void tcan4x5x_can_remove(struct spi_device *spi)
 
 	m_can_class_unregister(&priv->cdev);
 
-	tcan4x5x_power_enable(priv->power, 0);
+	tcan4x5x_power_enable(priv, 0);
 
 	m_can_class_free_dev(priv->cdev.net);
 }
diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 29de0c01e4edc..37c1c22c40c9f 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -50,6 +50,12 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
 		RKCANFD_QUIRK_CANFD_BROKEN,
 };
 
+static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3588 = {
+	.model = RKCANFD_MODEL_RK3588,
+	.quirks = RKCANFD_QUIRK_RK3568_ERRATUM_5 |
+		RKCANFD_QUIRK_RK3568_ERRATUM_6,
+};
+
 static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
 {
 	switch (model) {
@@ -57,6 +63,8 @@ static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
 		return "rk3568v2";
 	case RKCANFD_MODEL_RK3568V3:
 		return "rk3568v3";
+	case RKCANFD_MODEL_RK3588:
+		return "rk3588";
 	}
 
 	return "<unknown>";
@@ -148,6 +156,12 @@ static int rkcanfd_set_bittiming(struct rkcanfd_priv *priv)
 
 	rkcanfd_write(priv, RKCANFD_REG_FD_DATA_BITTIMING, reg_dbt);
 
+	/* RK3588 CAN-FD BRS works with TDC disabled. */
+	if (priv->devtype_data.model == RKCANFD_MODEL_RK3588) {
+		rkcanfd_write(priv, RKCANFD_REG_TRANSMIT_DELAY_COMPENSATION, 0);
+		return 0;
+	}
+
 	tdco = (priv->can.clock.freq / dbt->bitrate) * 2 / 3;
 	tdco = min(tdco, FIELD_MAX(RKCANFD_REG_TRANSMIT_DELAY_COMPENSATION_TDC_OFFSET));
 
@@ -846,6 +860,9 @@ static const struct of_device_id rkcanfd_of_match[] = {
 	}, {
 		.compatible = "rockchip,rk3568v3-canfd",
 		.data = &rkcanfd_devtype_data_rk3568v3,
+	}, {
+		.compatible = "rockchip,rk3588-canfd",
+		.data = &rkcanfd_devtype_data_rk3588,
 	}, {
 		/* sentinel */
 	},
diff --git a/drivers/net/can/rockchip/rockchip_canfd-rx.c b/drivers/net/can/rockchip/rockchip_canfd-rx.c
index 475c0409e215a..24e87daa1df00 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-rx.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-rx.c
@@ -281,7 +281,10 @@ rkcanfd_rx_fifo_get_len(const struct rkcanfd_priv *priv)
 {
 	const u32 reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);
 
-	return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT, reg);
+	if (priv->devtype_data.model == RKCANFD_MODEL_RK3588)
+		return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588, reg);
+
+	return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568, reg);
 }
 
 int rkcanfd_handle_rx_int(struct rkcanfd_priv *priv)
diff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h
index 93131c7d7f54d..95bea9bfd8a2f 100644
--- a/drivers/net/can/rockchip/rockchip_canfd.h
+++ b/drivers/net/can/rockchip/rockchip_canfd.h
@@ -214,7 +214,8 @@
 #define RKCANFD_REG_TXEVENT_FIFO_CTRL_TXE_FIFO_ENABLE BIT(0)
 
 #define RKCANFD_REG_RX_FIFO_CTRL 0x118
-#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT GENMASK(6, 4)
+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568 GENMASK(6, 4)
+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588 GENMASK(7, 5)
 #define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_FULL_WATERMARK GENMASK(3, 1)
 #define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_ENABLE BIT(0)
 
@@ -331,6 +332,11 @@
  * rarely with the standard clock of 300 MHz, but almost immediately
  * at 80 MHz.
  *
+ * Tests on the rk3588 show the same empty FIFO condition.
+ * In that setup rx_fifo_empty_errors increments when the bus
+ * transitions from idle to high CAN-FD load and stops growing once
+ * the bus reaches a steady state.
+ *
  * To workaround this problem, check for empty FIFO with
  * rkcanfd_fifo_header_empty() in rkcanfd_handle_rx_int_one() and exit
  * early.
@@ -344,6 +350,8 @@
 /* Erratum 6: The CAN controller's transmission of extended frames may
  * intermittently change into standard frames
  *
+ * Tests on the rk3588 show the same problem.
+ *
  * Work around this issue by activating self reception (RXSTX). If we
  * have pending TX CAN frames, check all RX'ed CAN frames in
  * rkcanfd_rxstx_filter().
@@ -424,6 +432,9 @@
  *     cansequence -rv -i 1
  *
  * - TX starvation after repeated Bus-Off
+ *   Tests on the rk3588 show the same problem. In a
+ *   10-cycle Bus-Off recovery test, 9 cycles failed to send after the
+ *   controller restarted.
  *   To reproduce:
  *   host:
  *     sleep 3 && cangen can0 -I2 -Li -Di -p10 -g 0.0
@@ -434,6 +445,7 @@
 enum rkcanfd_model {
 	RKCANFD_MODEL_RK3568V2 = 0x35682,
 	RKCANFD_MODEL_RK3568V3 = 0x35683,
+	RKCANFD_MODEL_RK3588 = 0x3588,
 };
 
 struct rkcanfd_devtype_data {
diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
index 82508a8650959..3b9b2f104d868 100644
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -1565,7 +1565,7 @@ static int gs_usb_probe(struct usb_interface *intf,
 
 	if (icount > type_max(parent->channel_cnt)) {
 		dev_err(&intf->dev,
-			"Driver cannot handle more that %u CAN interfaces\n",
+			"Driver cannot handle more than %u CAN interfaces\n",
 			type_max(parent->channel_cnt));
 		return -EINVAL;
 	}
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index e882250180ef6..9e2e25d024717 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -33,6 +33,7 @@ MODULE_ALIAS_RTNL_LINK(DRV_NAME);
 
 struct vxcan_priv {
 	struct net_device __rcu	*peer;
+	netdevice_tracker peer_tracker;
 };
 
 static netdev_tx_t vxcan_xmit(struct sk_buff *oskb, struct net_device *dev)
@@ -268,9 +269,11 @@ static int vxcan_newlink(struct net_device *dev,
 	/* cross link the device pair */
 	priv = netdev_priv(dev);
 	rcu_assign_pointer(priv->peer, peer);
+	netdev_hold(peer, &priv->peer_tracker, GFP_KERNEL);
 
 	priv = netdev_priv(peer);
 	rcu_assign_pointer(priv->peer, dev);
+	netdev_hold(dev, &priv->peer_tracker, GFP_KERNEL);
 
 	return 0;
 
@@ -281,24 +284,25 @@ static int vxcan_newlink(struct net_device *dev,
 
 static void vxcan_dellink(struct net_device *dev, struct list_head *head)
 {
+	netdevice_tracker *peer_tracker;
 	struct vxcan_priv *priv;
 	struct net_device *peer;
 
 	priv = netdev_priv(dev);
-	peer = rtnl_dereference(priv->peer);
+	peer_tracker = &priv->peer_tracker;
+	peer = unrcu_pointer(xchg(&priv->peer, NULL));
+	if (!peer)
+		return;
 
-	/* Note : dellink() is called from default_device_exit_batch(),
-	 * before a rcu_synchronize() point. The devices are guaranteed
-	 * not being freed before one RCU grace period.
-	 */
-	RCU_INIT_POINTER(priv->peer, NULL);
 	unregister_netdevice_queue(dev, head);
 
-	if (peer) {
-		priv = netdev_priv(peer);
-		RCU_INIT_POINTER(priv->peer, NULL);
-		unregister_netdevice_queue(peer, head);
-	}
+	priv = netdev_priv(peer);
+	dev = unrcu_pointer(xchg(&priv->peer, NULL));
+	if (dev)
+		unregister_netdevice_queue_net(dev_net(dev), peer, head);
+
+	netdev_put(peer, peer_tracker);
+	netdev_put(dev, &priv->peer_tracker);
 }
 
 static const struct nla_policy vxcan_policy[VXCAN_INFO_MAX + 1] = {

gemini-3.1-pro-preview

null

null

							input: 9498
							output: 165
							thoughts: 1763
						

**Patch Series Review: CAN Driver Updates**

Okay, let's break down this patch series. My initial impression is that this is a relatively straightforward set of updates across various CAN drivers. Nothing here screams "critical security vulnerability" at first glance, but let's dive deeper and ensure we haven't missed anything subtle.

First, we have changes to the device tree bindings for `rockchip,rk3568v2-canfd.yaml`, `ti,am3517-hecc.yaml`, and `xilinx,can.yaml`. These are critical for hardware configuration, but I don't anticipate any uninitialized memory issues or information leaks in these modifications alone. We just need to make sure the changes accurately reflect the hardware capabilities. Documentation is also updated (`fsm_txt_buffer_user.svg` and `MAINTAINERS`), which is always good to see.

Now, let's look at the driver-specific changes. In `m_can.c`, it looks like a simple update to how the "wakeup-source" property is read from the device tree, which shouldn't introduce any new security concerns. Similarly, the `m_can_pci.c` change just fixes the clock frequency, making sure the device gets the correct clock rate.

The most interesting change is in `vxcan.c`. Here, we see a correction using `netdevice_tracker` to handle refcounting on the peer devices in the virtual CAN interface. This directly addresses a potential use-after-free scenario. This is a solid fix and exactly the kind of thing we want to see. Given the nature of `vxcan.c`, KASAN should be able to catch the refcount errors, which simplifies the review.

The `tcan4x5x-core.c` update seems focused on enabling sleep mode in the hardware, which might expose bugs that require KASAN to catch, but it's unlikely to be security-relevant. It's important for power management, but the core function is just enabling or disabling hardware features.

The `rockchip_canfd-core.c`, `rockchip_canfd-rx.c`, and `rockchip_canfd.h` changes add support for the RK3588 SOC. This usually requires very careful review. However, in this case, the changes simply involve selecting the correct register fields based on the device model. It appears that the update is done in an explicit, safe way.

Finally, we have a typo fix in `gs_usb.c`.

Based on my analysis, these changes are a mix of device tree updates, hardware-specific fixes, and bug fixes for the drivers. Most importantly, none of these changes seem to introduce new vectors for uninitialized memory access, info-leaks, or complex data structures sent to userspace. The `vxcan.c` fix specifically addresses a refcounting/UAF, a classic problem that's already well-understood and typically caught by KASAN.

Therefore, my conclusion is that this patch series does *not* warrant a `NeedsKMSAN` label. The focus is more on stability and hardware support.

{
  "KMSANReasoning": "The patch series consists of device tree binding updates, hardware driver fixes (sleep mode handling in tcan4x5x, RK3588 support in rockchip_canfd, clock frequency in m_can_pci), and a refcounting/UAF fix in vxcan.c using netdevice_tracker. None of these changes introduce new data structures sent to userspace, modify bounds checking in a way that exposes uninitialized memory, or involve complex uninitialized state. The vxcan.c fix addresses a use-after-free/refcounting issue which is effectively caught by standard KASAN. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch series consists of device tree binding updates, hardware driver fixes (sleep mode handling in tcan4x5x, RK3588 support in rockchip_canfd, clock frequency in m_can_pci), and a refcounting/UAF fix in vxcan.c using netdevice_tracker. None of these changes introduce new data structures sent to userspace, modify bounds checking in a way that exposes uninitialized memory, or involve complex uninitialized state. The vxcan.c fix addresses a use-after-free/refcounting issue which is effectively caught by standard KASAN. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}