kernel/linux.git/drivers/net/mctp, branch v6.18.44

mctp: serial: handle zero-length frames to prevent rx buffer overflow

2026-08-03T09:22:05+00:00

commit 793b9b729f1e8de57be8c8daf1a9838be96cabed upstream. The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: if (c > MCTP_SERIAL_FRAME_MTU) { dev->rxstate = STATE_ERR; } else { dev->rxlen = c; dev->rxpos = 0; dev->rxstate = STATE_DATA; ... } A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is tested: dev->rxbuf[dev->rxpos] = c; dev->rxpos++; dev->rxstate = STATE_DATA; if (dev->rxpos == dev->rxlen) { dev->rxpos = 0; dev->rxstate = STATE_TRAILER; } With rxlen == 0 the "rxpos == rxlen" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: a0c2ccd9b5ad ("mctp: Add MCTP-over-serial transport binding") Cc: stable@vger.kernel.org Suggested-by: Jeremy Kerr Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260715082021.46315-1-doruk@0sec.ai Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman

net: mctp i3c: clean up notifier and buses if driver register fails

2026-08-03T09:21:42+00:00

[ Upstream commit 03d1057305ef17ac3f5936ac1580bc9a1a826e14 ] mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: c8755b29b58e ("mctp i3c: MCTP I3C driver") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Jeremy Kerr Link: https://patch.msgid.link/20260715072517.13216-1-mhun512@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: mctp: usb: don't fail mctp_usb_rx_queue on a deferred submission

2026-06-19T11:43:59+00:00

[ Upstream commit 881a3113b74964918cdd72747e3bc119c02b0c0c ] In the ndo_open path, a deferred queue open will report a failure, and so the netdev will not be ndo_stop()ed, leaving us with the rx_retry work potentially pending. Don't report a deferred queue as an error, as we are still operational. This means we use the ndo_stop() path for future cleanup, which handles rx_retry_work cancellation. Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20260608-dev-mctp-usb-rx-requeue-v2-2-29a3aa507609@codeconstruct.com.au Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

net: mctp: usb: fix race between urb completion and rx_retry cancellation

2026-06-19T11:43:59+00:00

[ Upstream commit 54665dce982689e2fd99b32e9a0dcc204fda8a51 ] It's possible that sequencing between setting ->stopped and cancelling the rx_retry work (in ndo_stop) could leave us with an urb queued: T1: ndo_stop T2: rx_retry_work ------------ ---------------- LD: ->stopped => false ST: ->stopped <= true usb_kill_urb() mctp_usb_rx_queue() usb_submit_urb() cancel_delayed_work_sync() That urb completion can then re-schedule rx_retry_work. Strenghen the sequencing between the stop (preventing another requeue) and the cancel by updating both atomically under a new rx lock. After setting ->rx_stopped, and cancelling pending work, we know that the requeue cannot occur, so all that's left is killing any pending urb. Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20260608-dev-mctp-usb-rx-requeue-v2-1-29a3aa507609@codeconstruct.com.au Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

net: mctp i2c: check length before marking flow active

2026-05-23T11:07:10+00:00

[ Upstream commit 4ca07b9239bd0478ae586632a2ed72be37ed8407 ] Currently, mctp_i2c_get_tx_flow_state() is called before the packet length sanity check. This function marks a new flow as active in the MCTP core. If the sanity check fails, mctp_i2c_xmit() returns early without calling mctp_i2c_lock_nest(). This results in a mismatched locking state: the flow is active, but the I2C bus lock was never acquired for it. When the flow is later released, mctp_i2c_release_flow() will see the active state and queue an unlock marker. The TX thread will then decrement midev->i2c_lock_count from 0, causing it to underflow to -1. This underflow permanently breaks the driver's locking logic, allowing future transmissions to occur without holding the I2C bus lock, leading to bus collisions and potential hardware hangs. Move the mctp_i2c_get_tx_flow_state() call to after the length sanity check to ensure we only transition the flow state if we are actually going to proceed with the transmission and locking. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Signed-off-by: William A. Kennington III Acked-by: Jeremy Kerr Link: https://patch.msgid.link/20260423074741.201460-1-william@wkennington.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

net: mctp: fix device leak on probe failure

2026-03-19T15:08:40+00:00

commit 224a0d284c3caf1951302d1744a714784febed71 upstream. Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. This driver takes a reference to the USB device during probe but does not to release it on probe failures. Drop the redundant device reference to fix the leak, reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of further memory leaks. Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Cc: stable@vger.kernel.org # 6.15 Signed-off-by: Johan Hovold Acked-by: Jeremy Kerr Link: https://patch.msgid.link/20260305104549.16110-1-johan@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

mctp: i2c: fix skb memory leak in receive path

2026-03-19T15:08:16+00:00

[ Upstream commit e3f5e0f22cfc2371e7471c9fd5b4da78f9df7c69 ] When 'midev->allow_rx' is false, the newly allocated skb isn't consumed by netif_rx(), it needs to free the skb directly. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Signed-off-by: Haiyue Wang Link: https://patch.msgid.link/20260305143240.97592-1-haiyuewa@163.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

mctp i2c: initialise event handler read bytes

2026-02-26T22:59:16+00:00

[ Upstream commit 2a14e91b6d76639dac70ea170f4384c1ee3cb48d ] Set a 0xff value for i2c reads of an mctp-i2c device. Otherwise reads will return "val" from the i2c bus driver. For i2c-aspeed and i2c-npcm7xx that is a stack uninitialised u8. Tested with "i2ctransfer -y 1 r10@0x34" where 0x34 is a mctp-i2c instance, now it returns all 0xff. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Signed-off-by: Matt Johnston Link: https://patch.msgid.link/20260113-mctp-read-fix-v1-1-70c4b59c741c@codeconstruct.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: mctp-i2c: fix duplicate reception of old data

2026-02-26T22:59:16+00:00

[ Upstream commit ae4744e173fadd092c43eda4ca92dcb74645225a ] The MCTP I2C slave callback did not handle I2C_SLAVE_READ_REQUESTED events. As a result, i2c read event will trigger repeated reception of old data, reset rx_pos when a read request is received. Signed-off-by: Jian Zhang Link: https://patch.msgid.link/20260108101829.1140448-1-zhangjian.3032@bytedance.com Signed-off-by: Jakub Kicinski Stable-dep-of: 2a14e91b6d76 ("mctp i2c: initialise event handler read bytes") Signed-off-by: Sasha Levin

net: mctp: Fix tx queue stall

2025-10-30T00:55:14+00:00

The tx queue can become permanently stuck in a stopped state due to a race condition between the URB submission path and its completion callback. The URB completion callback can run immediately after usb_submit_urb() returns, before the submitting function calls netif_stop_queue(). If this occurs, the queue state management becomes desynchronized, leading to a stall where the queue is never woken. Fix this by moving the netif_stop_queue() call to before submitting the URB. This closes the race window by ensuring the network stack is aware the queue is stopped before the URB completion can possibly run. Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Signed-off-by: Jinliang Wang Acked-by: Jeremy Kerr Link: https://patch.msgid.link/20251027065530.2045724-1-jinliangw@google.com Signed-off-by: Jakub Kicinski