greybus-dev October 2026

greybus-dev@lists.linaro.org

28 participants
39 discussions

[PATCH v4 0/6] Add Greybus Sotfsvc and UART Node drivers

by Ayush Singh

A Greybus network needs an SVC (Supervisory Controller) to bring interfaces up, assign device IDs and connect CPorts to the AP. On a UniPro network the SVC is a real entity on the bus. On transports that merely carry Greybus messages - a UART, an I2C bus, a network link - nothing on the wire plays that role, so the SVC has to be emulated somewhere: in a user-space bridge (gbridge), in coprocessor firmware (cc1352p7 in gb-beagleplay), or open-coded inside the host driver itself. This series moves the emulation into the kernel and makes it shared. This was discussed in a prior RFC as well [2], but to keep things short, removing the need for an external SVC greatly simplifies the greybus network setup when nodes are directly connected over common transports such as UART, I2C etc. gb-uart-node gb-softsvc greybus core (transport, serdev) <-> (SVC + host device) <-> (bundles, protocols) NodeOps module_insert() submit_message() module_remove() gb-softsvc registers itself as a Greybus host device and answers the SVC-side operations the core expects during interface bring-up and teardown. A host driver implements the NodeOps trait to push data towards its node, calls module_insert() to announce a new node, submit_message() to hand incoming Greybus messages back to the core, and module_remove() on disconnect. The first user is gb-uart-node, a driver for Greybus nodes attached over a plain serial port. Framing is HDLC, with a one-byte address (0x01 for Greybus) and control byte, followed by the 16-bit CPort ID and the Greybus message. No SVC firmware is required on the far end, so the node can be a bare microcontroller speaking Greybus - a BeagleConnect Freedom over its serial link, in this case. The testing is performed with greybus-zephyr [0] implementation. Both drivers are written in Rust, which is why the middle of the series is abstractions rather than drivers. Only the APIs these two drivers need are covered: protocols.rs abstracts the SVC-facing parts of greybus_protocols.h, and types such as Greybus Interface do not implement AlwaysRefCounted yet. The intent is to grow this as more Rust host drivers appear rather than to abstract the whole subsystem up front. Patches 1 and 2 are small C-side preparations to the Greybus core: exporting gb_connection_get()/gb_connection_put() and adding gb_connection_hd_find_by_intf(), a lookup by remote interface and CPort id for callers that only know the far end of a connection. Patch 3 adds a CRC-CCITT abstraction, needed for HDLC frame checks. Patch 4 adds the Greybus abstractions, patches 5 and 6 the two drivers, and patch 7 the device tree binding for BeagleConnect Freedom. Open questions *************** - gb-uart-node imports types from gb-softsvc, so the series carries the Rust-to-Rust cross-module calling setup from nova-core [1]: gb_softsvc_exports.c plus the Makefile plumbing that emits crate metadata and generates the export list. This is a workaround for the build system not supporting Rust cross-module dependencies natively, and it should go away once that lands. - Connection create/destroy and interface activate/resume in gb-softsvc currently just acknowledge the request. Callbacks into NodeOps can be added when a transport actually needs to act on them; I did not want to invent an interface without a user. - Zerocopy is currently not being used in grebeybus/protocols.rs. They cannot be derived yet since types generated by bindgen do not have them, and it seems explicitly forbindden to manually impl the traits. So using old traits from transmute. - The bindings are supposed to be created for actual device, but any MCU that supports Zephyr, can run the greybus-zephyr firmware with UART transport. So not sure if adding a beagle,beagleconnect-freedom compatible is the correct choice here. - The individual patches can be spun off into independent patch series if required. The reason for this single patch series is to provide a complete picture of usage. - Since gb-softsvc currently is not being used from a C driver, no C API is provided. However, if required, it can be added. - Writing to UART from gb-uart-node is currently a bit broken. I am not quite sure what the safe way is to go from a non-bound device to a bound device. Any suggestions on this front are welcome. - I am not sure if Rust abstractions should have a seperate entry in MAINTAINERS with me as the maintainer, or if they should just be added to the respective subsystem entries. As mentioned by Miguel Ojeda [3], this is upto greybus maintainers. So waiting on their inputs. I am available to be maintainer for the Rust abstractions for greybus if required. [0]: https://github.com/beagleboard/greybus-zephyr [1]: https://lore.kernel.org/all/20260622-nova-exports-v5-0-6191773fc977@nvidia.… [2]: https://lore.kernel.org/all/ecca8eb2-8e5a-4770-bcf6-3fb49773088b@beagleboar… [3]: https://lore.kernel.org/all/CANiq72mA6pTmPJUk8g7y3Z=wetFMXdzHLiPEPChpY4OTg3… Signed-off-by: Ayush Singh <ayush(a)beagleboard.org> --- Changes in v4: - Remove gb_uard_node::GbUartNode::unbind. Suggested by Markus Probst, since write is still valid after unbind. - Add inline attribute where suggested. - Remove patch 1. No longer required with modifications to the old patch 2. - Increse hdlc max buffer size to 512 bytes. - Send module_removed request before removing from map. - Also do not hold lock across interface drop. - Link to v3: https://lore.kernel.org/r/20261013-gb-uart-transport-v3-0-81d0a8a1acf7@beag… Changes in v3: - Fix incorrect email in MAINTAINERS. - Make CONFIG_RUST_GREYBUS_ABSTRACTIONS depend on sysfs like CONFIG_GREYBUS. - Fix cleanup in hd::Registration::new in case of errors. - Fix comments. - Fix Msg AsBytes impl as suggested by sashiko-bot. - Use SpinLock for intf_map. This should be fine since we need locking only for getting the interface. We do not hold locks across operations. - Properly drop message in case of buffer overflow in gb_uart_node. - Link to v2: https://lore.kernel.org/r/20260827-gb-uart-transport-v2-0-a03bb1f5fbd1@beag… Changes in v2: - Fix possible null pointer dereference in gb_connection_hd_find_by_intf. Flagged by sashiko-bot. - Remove prompt CONFIG_RUST_CRC_CCITT_ABSTRACTIONS Kconfig symbol. - Add CONFIG_RUST_GREYBUS_ABSTRACTIONS to ensure that greybus is built-in for rust abstractions to work. - Use gfp_mask in message_send callback. - Only provide a Message reference in message_cancel callback. - Add invariant comment for Registration. - Call Registration->add directly in new, before constructing Registration. - Add Send and Sync bounds to T in Registration<T> - Set endo_id as 0. Is not used anywhere. - Fix module_insert intf_count. Was hardcoded to 1 by mistake. Flagged by sashiko-bot. - Check for empty intfs slice in Module::new. - Remove module in serdev::Driver::unbind instead of on drop. - Make gb_uart_node write atomic. Using temp buffer to build frame. - Fix import style. - Reorder beagleconnect-freedom dtbinding patch to be before gb_uart_node. - Add vbat-supply and reg properties to beagleconnect-freedom dtbinding. - Reference spi-peripheral-props in beagleconnect-freedom dtbinding. - Link to v1: https://lore.kernel.org/r/20260820-gb-uart-transport-v1-0-282da14ab7b7@beag… --- Ayush Singh (6): greybus: connection: Add greybus_data_rcvd_by_intf() rust: crc_ccitt: add CRC-CCITT abstraction rust: kernel: Add greybus abstractions drivers: greybus: Add software SVC implementation dt-bindings: beagle: Add BeagleConnect Freedom greybus: Add Rust UART node driver .../beagle/beagle,beagleconnect-freedom.yaml | 62 +++ MAINTAINERS | 15 + drivers/greybus/.gitignore | 1 + drivers/greybus/Kconfig | 35 ++ drivers/greybus/Makefile | 50 ++ drivers/greybus/connection.c | 47 ++ drivers/greybus/gb_softsvc.rs | 520 +++++++++++++++++++++ drivers/greybus/gb_softsvc_exports.c | 15 + drivers/greybus/gb_uart_node.rs | 257 ++++++++++ include/linux/greybus/connection.h | 2 + lib/crc/Kconfig | 7 + rust/bindings/bindings_helper.h | 2 + rust/kernel/alloc.rs | 6 + rust/kernel/crc_ccitt.rs | 26 ++ rust/kernel/greybus/hd.rs | 362 ++++++++++++++ rust/kernel/greybus/mod.rs | 220 +++++++++ rust/kernel/greybus/protocols.rs | 442 ++++++++++++++++++ rust/kernel/lib.rs | 4 + 18 files changed, 2073 insertions(+) --- base-commit: becb95e45ef0dda9ffb35156d909d3da7a2789c3 change-id: 20260810-gb-uart-transport-9255d6557c4c Best regards, -- Ayush Singh <ayush(a)beagleboard.org>

4 minutes

[PATCH v2] staging: greybus: Align function arguments

by pavankumaryalagada＠gmail.com

From: Yalagada Pavan Kumar <pavankumaryalagada(a)gmail.com> Align the function arguments to follow the coding style and improve readability, addressing the alignment warning reported by checkpatch.pl Signed-off-by: Yalagada Pavan Kumar <pavankumaryalagada(a)gmail.com> --- v2: - Rebased onto staging-next. v1: https://lore.kernel.org/outreachy/C560A15E-6F28-4FC8-8BE2-277B503340AD@inri… drivers/staging/greybus/loopback.c | 3 ++- drivers/staging/greybus/spilib.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c index fe48a687377a..efc69c10cffe 100644 --- a/drivers/staging/greybus/loopback.c +++ b/drivers/staging/greybus/loopback.c @@ -652,7 +652,8 @@ static int gb_loopback_request_handler(struct gb_operation *operation) } if (!gb_operation_response_alloc(operation, - len + sizeof(*response), GFP_KERNEL)) { + len + sizeof(*response), + GFP_KERNEL)) { dev_err(dev, "error allocating response\n"); return -ENOMEM; } diff --git a/drivers/staging/greybus/spilib.c b/drivers/staging/greybus/spilib.c index e4d1ae8308aa..c1982f3fb931 100644 --- a/drivers/staging/greybus/spilib.c +++ b/drivers/staging/greybus/spilib.c @@ -160,7 +160,8 @@ static struct spi_transfer *get_next_xfer(struct spi_transfer *xfer, /* Routines to transfer data */ static struct gb_operation *gb_spi_operation_create(struct gb_spilib *spi, - struct gb_connection *connection, struct spi_message *msg) + struct gb_connection *connection, + struct spi_message *msg) { struct gb_spi_transfer_request *request; struct spi_device *dev = msg->spi; -- 2.43.0

7 hours, 22 minutes

[PATCH v2] staging: greybus: remove unnecessary goto

by Haasham Khan

Remove the conditional jump to gb_error, as both success and error paths proceed to free the request and return the result. This simplifies the control flow without changing the function's behavior. Signed-off-by: Haasham Khan <haasham93(a)gmail.com> --- drivers/staging/greybus/loopback.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c index efc69c10cffe..284935fded12 100644 --- a/drivers/staging/greybus/loopback.c +++ b/drivers/staging/greybus/loopback.c @@ -609,10 +609,6 @@ static int gb_loopback_async_transfer(struct gb_loopback *gb, u32 len) request, len + sizeof(*request), len + response_len, gb_loopback_async_transfer_complete); - if (retval) - goto gb_error; - -gb_error: kfree(request); return retval; } -- 2.53.0

18 hours, 35 minutes

[PATCH 1/1] staging: greybus: remove unnecessary goto

by Haasham Khan

Signed-off-by: Haasham Khan <haasham93(a)gmail.com> --- drivers/staging/greybus/loopback.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c index efc69c10cffe..284935fded12 100644 --- a/drivers/staging/greybus/loopback.c +++ b/drivers/staging/greybus/loopback.c @@ -609,10 +609,6 @@ static int gb_loopback_async_transfer(struct gb_loopback *gb, u32 len) request, len + sizeof(*request), len + response_len, gb_loopback_async_transfer_complete); - if (retval) - goto gb_error; - -gb_error: kfree(request); return retval; } -- 2.53.0

20 hours

[syzbot] [greybus?] WARNING: ODEBUG bug in gb_operation_put

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 893584e7e390 Merge tag 'usb-serial-7.4-rc1' of ssh://gitol.. git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing console output: https://syzkaller.appspot.com/x/log.txt?x=15d65da9580000 kernel config: https://syzkaller.appspot.com/x/.config?x=7f0127eb11110629 dashboard link: https://syzkaller.appspot.com/bug?extid=61464b62b688791cc24c compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17d7c621580000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12828121580000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/7fc735ea948d/disk-893584e7.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/546995671e2c/vmlinux-893584e7.… kernel image: https://storage.googleapis.com/syzbot-assets/54ff06887775/bzImage-893584e7.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+61464b62b688791cc24c(a)syzkaller.appspotmail.com greybus greybus1: 0/0:0: synchronous operation id 0x0003 of type 0x14 failed: -71 ------------[ cut here ]------------ ODEBUG: free active (active state 0) object: ffff88811ce2bad8 object type: timer_list hint: gb_operation_timeout+0x0/0xe0 drivers/greybus/operation.c:1211 WARNING: lib/debugobjects.c:629 at debug_print_object+0x198/0x2b0 lib/debugobjects.c:629, CPU#1: kworker/u8:1/33 Modules linked in: CPU: 1 UID: 0 PID: 33 Comm: kworker/u8:1 Not tainted syzkaller #0 PREEMPT(lazy) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/16/2026 Workqueue: greybus1:0 gb_operation_work RIP: 0010:debug_print_object+0x1a5/0x2b0 lib/debugobjects.c:629 Code: b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 48 8d 3d f8 be 37 08 41 56 48 8b 14 ed 40 cf d2 87 4c 89 e6 <67> 48 0f b9 3a 58 83 05 d2 16 33 08 01 48 83 c4 18 5b 5d 41 5c 41 RSP: 0018:ffffc90000237868 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc90000237950 RCX: 0000000000000000 RDX: ffffffff87d2ce80 RSI: ffffffff87d2ca20 RDI: ffffffff8b1aa8a0 RBP: 0000000000000003 R08: ffff88811ce2bad8 R09: ffffffff87ad4ea0 R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff87d2ca20 R13: ffffffff87ad4ee0 R14: ffffffff861dd740 R15: ffffc90000237968 FS: 0000000000000000(0000) GS:ffff8882684d7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f27a5b70220 CR3: 00000001176ce000 CR4: 00000000003506f0 Call Trace: <TASK> __debug_check_no_obj_freed lib/debugobjects.c:1171 [inline] debug_check_no_obj_freed+0x4da/0x630 lib/debugobjects.c:1201 slab_free_hook mm/slub.c:2679 [inline] slab_free mm/slub.c:6509 [inline] kmem_cache_free+0x398/0x650 mm/slub.c:6636 _gb_operation_destroy drivers/greybus/operation.c:682 [inline] kref_put include/linux/kref.h:65 [inline] gb_operation_put+0x1b2/0x3c0 drivers/greybus/operation.c:694 gb_operation_sync_timeout+0x193/0x220 drivers/greybus/operation.c:1172 gb_operation_sync include/linux/greybus/operation.h:203 [inline] gb_svc_pwrmon_rail_count_get drivers/greybus/svc.c:137 [inline] gb_svc_pwrmon_debugfs_init drivers/greybus/svc.c:772 [inline] gb_svc_debugfs_init drivers/greybus/svc.c:827 [inline] gb_svc_hello drivers/greybus/svc.c:875 [inline] gb_svc_request_handler+0x515/0x1250 drivers/greybus/svc.c:1276 gb_operation_request_handle drivers/greybus/operation.c:243 [inline] gb_operation_work+0xb7/0x990 drivers/greybus/operation.c:280 process_one_work+0xac7/0x1b10 kernel/workqueue.c:3396 process_scheduled_works kernel/workqueue.c:3479 [inline] worker_thread+0x5ef/0xe50 kernel/workqueue.c:3560 kthread+0x373/0x450 kernel/kthread.c:436 ret_from_fork+0x69f/0xc90 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> ---------------- Code disassembly (best guess): 0: b8 00 00 00 00 mov $0x0,%eax 5: 00 fc add %bh,%ah 7: ff lcall (bad) 8: df 48 89 fisttps -0x77(%rax) b: fa cli c: 48 c1 ea 03 shr $0x3,%rdx 10: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) 14: 75 4f jne 0x65 16: 48 8d 3d f8 be 37 08 lea 0x837bef8(%rip),%rdi # 0x837bf15 1d: 41 56 push %r14 1f: 48 8b 14 ed 40 cf d2 mov -0x782d30c0(,%rbp,8),%rdx 26: 87 27: 4c 89 e6 mov %r12,%rsi * 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction 2f: 58 pop %rax 30: 83 05 d2 16 33 08 01 addl $0x1,0x83316d2(%rip) # 0x8331709 37: 48 83 c4 18 add $0x18,%rsp 3b: 5b pop %rbx 3c: 5d pop %rbp 3d: 41 5c pop %r12 3f: 41 rex.B --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. If the report is already addressed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to overwrite report's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the report is a duplicate of another one, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup

21 hours, 8 minutes

[PATCH 1/1] staging: greybus: remove unnecessary goto

by Haasham Khan

22 hours, 21 minutes

[PATCH v6] staging: greybus: remove redundant error message

by pavankumaryalagada＠gmail.com

From: Yalagada Pavan Kumar <pavankumaryalagada(a)gmail.com> Remove the error message, as tty_alloc_driver() returns -ENOMEM when it fails, so printing the message is unnecessary. Signed-off-by: Yalagada Pavan Kumar <pavankumaryalagada(a)gmail.com> Reviewed-by: Alex Elder <elder(a)riscstar.com> --- v6: - Remove the redundant error message, as suggested by Johan Hovold v5: - Drop arche-apb-ctrl.c and arche-platform.c changes because the files were removed. - keep only the uart.c change, as the fw-core.c changes are already present in staging/staging-next. v4: - Return error codes directly instead of storing them in ret, as suggested by Julia Lawall. - Remove the unused ret variable. v3: - Extend the %pe conversion throughout Greybus, as suggested by Alex Elder. v2: - Use %pe in the firmware management case, as suggested by Jeremy Clifton, to match the other cases. v1: https://lore.kernel.org/outreachy/as0nhVbagZa8Birm@user/T/#t --- drivers/staging/greybus/uart.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c index d47f00751e7a..4de61fca6725 100644 --- a/drivers/staging/greybus/uart.c +++ b/drivers/staging/greybus/uart.c @@ -956,7 +956,6 @@ static int gb_tty_init(void) gb_tty_driver = tty_alloc_driver(GB_NUM_MINORS, TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV); if (IS_ERR(gb_tty_driver)) { - pr_err("Can not allocate tty driver\n"); retval = PTR_ERR(gb_tty_driver); goto fail_unregister_dev; } -- 2.43.0

1 day, 21 hours

[PATCH AUTOSEL 6.18-5.10] greybus: manifest: validate string descriptor header

by Sasha Levin

From: Pengpeng Hou <pengpeng(a)iscas.ac.cn> [ Upstream commit 18b6510f642dbcb856c3af8be974d1600f3ba2d3 ] identify_descriptor() computes a string descriptor size from desc->string.length. Require the descriptor to contain the fixed string descriptor header before reading the variable string length. The existing descriptor-size check then reports the short descriptor. Signed-off-by: Pengpeng Hou <pengpeng(a)iscas.ac.cn> Link: https://patch.msgid.link/20260706091935.78020-1-pengpeng@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: The local tree is **v7.3-rc4** (mainline 7.3.0-rc4). Greybus manifest parsing exists here, the two-line size check is already the current code, and the same parser has been in the kernel since v4.9. The rest of this write-up is whether that fix is stable-worthy for this lineage. =============================================================== PHASE 1: COMMIT MESSAGE FORENSICS =============================================================== **Step 1.1: PARSE THE SUBJECT LINE** Record: **[greybus/manifest] [validate] [require the fixed string- descriptor header before reading `desc->string.length`]** **Step 1.2: PARSE ALL COMMIT MESSAGE TAGS** Record: - `Fixes:` — none (expected for this review path) - `Reported-by:` — none - `Tested-by:` — none - `Reviewed-by:` — none - `Acked-by:` — none - `Link:` https://patch.msgid.link/20260706091935.78020-1-pengpeng@iscas.ac.cn - `Cc: stable(a)vger.kernel.org` — none (expected) - `Signed-off-by: Pengpeng Hou <pengpeng(a)iscas.ac.cn>` (author) - `Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>` (greybus maintainer; ignore any Sasha Levin SOB — none present) Notable pattern: no user/syzbot report; maintainer still took the patch. **Step 1.3: ANALYZE THE COMMIT BODY TEXT** Record: - **Bug:** `identify_descriptor()` uses `desc->string.length` to compute expected size before the descriptor is known to contain the two-byte string header (`length` + `id`). - **Symptom:** out-of-bounds / out-of-object read of `length` on a truncated `GREYBUS_TYPE_STRING` descriptor. - **Failure mode:** malformed hardware manifest; heap OOB when remaining buffer is only the 4-byte generic header. - **Version info:** none in the message. - **Root cause (author):** read variable length before the fixed string header is present; the existing `desc_size < expected_size` path then reports the short descriptor. **Step 1.4: DETECT HIDDEN BUG FIXES** Record: **Not disguised.** Subject/body describe a bounds check. It *is* a real memory-safety fix, not cleanup. =============================================================== PHASE 2: DIFF ANALYSIS - LINE BY LINE =============================================================== **Step 2.1: INVENTORY THE CHANGES** Record: - File: `drivers/greybus/manifest.c` — **+2 / -0** - Function: `identify_descriptor()` - Scope: **single-file surgical fix** **Step 2.2: UNDERSTAND THE CODE FLOW CHANGE** Record: Before, `GREYBUS_TYPE_STRING` did `expected_size += sizeof(struct greybus_descriptor_string)` then immediately `expected_size += desc->string.length`. After, if `desc_size < expected_size` (header + 2-byte string header), it `break`s into the existing “descriptor too small” `-EINVAL` path and never reads `length`. **Step 2.3: IDENTIFY THE BUG MECHANISM** Record: **[Memory safety / OOB read]**. `greybus_descriptor_header` is 4 bytes; `greybus_descriptor_string` is 2 bytes plus a flexible array. A descriptor with `size==4` and `type==STRING` is accepted by `desc_size > size` (4 is not greater than remaining size) but `desc->string.length` sits at offset 4. Manifest memory is `kmalloc(size)` in `gb_interface_enable()`, so when remaining length is 4 this is a **1-byte heap OOB read**. **Step 2.4: ASSESS THE FIX QUALITY** Record: **Obviously correct and minimal.** Valid string descriptors already have `desc_size >= 6 + length` (then 4-byte aligned); the new check cannot fire on them. `break` (not `return`) reuses the existing error log. Regression risk is **very low**. =============================================================== PHASE 3: GIT HISTORY INVESTIGATION =============================================================== **Step 3.1: BLAME THE CHANGED LINES** Record: The `length` access comes from **b09c94a1b71c82** (“greybus: start improving manifest parsing”, 2014-10-01, **v4.9-rc1**). Padding/`ALIGN` later: fa2fbf16f6aaaa (Viresh Kumar, 2015). The two new lines are this commit (**18b6510f642dbc**, Pengpeng Hou, 2026-07-06). Long-lived bug, not new code. **Step 3.2: FOLLOW THE FIXES: TAG** Record: **No `Fixes:` tag.** The introducing commit is b09c94a1b71c82, in this tree (`git merge-base --is-ancestor 18b6510f642db HEAD` succeeded). No intermediate fix of this specific hole. **Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES** Record: Recent `manifest.c` history is alloc-style churn plus the 2019 staging move (`8465def499c70`, **v5.4-rc1**). Older related work: fa2fbf16f6aaa (padding), cbd0fd7b9b6fd (length field type). **Standalone**, not patch N/M. **Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS** Record: Pengpeng Hou is not a Greybus maintainer. Other Greybus work: `1214bf28965ce` and `cbc96a916b1a3` (BeaglePlay RX bounds). Pattern of bounds checks, not a prerequisite series for this hunk. **Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS** Record: **No dependencies.** Uses existing `desc_size`, `expected_size`, and the existing too-small check. Can apply standalone. =============================================================== PHASE 4: MAILING LIST AND EXTERNAL RESEARCH =============================================================== **Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION** Record: - `b4 dig -c 18b6510f642db` → https://patch.msgid.link/20260706091935.78020-1-pengpeng@iscas.ac.cn - `b4 dig -a`: **v1 only** (2026-07-06) - Thread (mbox): author patch + Greg KH: “Nice, but how was this tested? How was it found?” - **No author reply found** on LKML, greybus-dev (Linaro), or the saved mbox. - Greg still applied it (commit date 2026-07-17). - No NAK. No reviewer `Cc: stable`. **Step 4.2: CHECK WHO REVIEWED THE PATCH** Record (`b4 dig -w`): To/Cc Johan Hovold, Alex Elder, Greg Kroah- Hartman, greybus-dev, linux-kernel — the GREYBUS SUBSYSTEM maintainers. Greg applied it; no Reviewed-by from Johan/Alex. **Step 4.3: SEARCH FOR THE BUG REPORT** Record: **No bugzilla/syzbot/CVE.** Discovery method unanswered (likely static review). Severity is from code, not a user report. **Step 4.4: CHECK FOR RELATED PATCHES AND SERIES** Record: **Standalone v1.** Other Hou Greybus patches are BeaglePlay RX bounds, not needed here. **Step 4.5: CHECK STABLE MAILING LIST HISTORY** Record: lore.kernel.org/stable/ returned **403**. No stable-thread hit via web search. **UNVERIFIED** whether stable@ discussed this. =============================================================== PHASE 5: CODE SEMANTIC ANALYSIS =============================================================== **Step 5.1: IDENTIFY KEY FUNCTIONS** Record: `identify_descriptor()` (modified). Callers/helpers: `gb_manifest_parse()`, `gb_interface_enable()`, `gb_control_get_manifest_*()`. **Step 5.2: TRACE CALLERS** Record: `identify_descriptor` is static; only called from `gb_manifest_parse()` while walking descriptors. `gb_manifest_parse` is called from `gb_interface_enable()` (`drivers/greybus/interface.c`). That is used from `gb_module_register_interface()` and other enable/resume paths in `interface.c`. **Device enable**, not a syscall. **Step 5.3: TRACE CALLEES** Record: `le16_to_cpu`, `dev_err`/`dev_warn`, `kzalloc_obj`, `list_add_tail`. No new locks/allocs in the patch. **Step 5.4: FOLLOW THE CALL CHAIN** Record: Greybus module/interface enable → control `GET_MANIFEST_SIZE` / `GET_MANIFEST` over the Greybus control CPort → `kmalloc(size)` → `gb_manifest_parse`. Trigger is **attached Greybus hardware** (BeaglePlay SVC, ES2 USB host, etc.), not unprivileged syscalls. Manifest bytes are **device-supplied**. **Step 5.5: SEARCH FOR SIMILAR PATTERNS** Record: Other descriptor types only add a fixed `sizeof()` and do not read extra fields before the later size check. This hole is **string- specific**. `gb_string_get()` copies `desc_string->length` after identify; that path is only reached if identify accepted the descriptor. =============================================================== PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE =============================================================== **Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?** Record: **Yes.** `drivers/greybus/manifest.c` `identify_descriptor()`; structs in `include/linux/greybus/greybus_manifest.h`. Bug since **v4.9**; core moved out of staging in **v5.4**. This checkout already contains **18b6510f642db**. **Step 6.2: CHECK FOR BACKPORT COMPLICATIONS** Record: **Clean apply** — two lines in an unchanged `switch` arm. Surrounding code matches the pre-image (aside from later `kzalloc_obj`). **Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE** Record: No earlier equivalent check. No later `manifest.c` commits after this one. =============================================================== PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT =============================================================== **Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY** Record: **Greybus core parser** (`drivers/greybus/`). Criticality: **PERIPHERAL/IMPORTANT** — not mm/VFS, but in-tree (not staging) core used by BeaglePlay and ES2. Parser of untrusted device blobs is the same class as USB descriptor parsing. **Step 7.2: ASSESS SUBSYSTEM ACTIVITY** Record: Mature; `manifest.c` is low-churn since the 2019 move. Bug is old, not a new-API refactor. =============================================================== PHASE 8: IMPACT AND RISK ASSESSMENT =============================================================== **Step 8.1: DETERMINE WHO IS AFFECTED** Record: **Config-specific + driver-specific** (`CONFIG_GREYBUS`, plus a module that supplies a manifest). Not universal. **Step 8.2: DETERMINE THE TRIGGER CONDITIONS** Record: Malformed string descriptor during interface enable. Needs Greybus hardware (or an equivalent host). **Not** a normal unprivileged syscall. Timing-independent. Commonness: rare (buggy/malicious module). **Step 8.3: DETERMINE THE FAILURE MODE SEVERITY** Record: **1-byte (typical) slab OOB read.** After the bad read, `expected_size` is still `>= 8` when `desc_size < 6`, so the existing check still returns `-EINVAL` — the OOB does not accept the descriptor. Production effect is usually KASAN/syz-style detection, not a guaranteed panic. Severity: **HIGH** as memory safety on untrusted device data; practical crash risk **MEDIUM**. **Step 8.4: CALCULATE RISK-BENEFIT RATIO** Record: - **Benefit:** stops a real OOB in a device-blob parser; tiny; long- present bug. - **Risk:** very low (2 lines, error path only, valid manifests unchanged). - **Ratio:** **favorable**. =============================================================== PHASE 9: FINAL SYNTHESIS =============================================================== **Step 9.1: COMPILE THE EVIDENCE** FOR: - Real OOB read of `desc->string.length` before the 2-byte string header is known to be in-bounds. - Manifest is kmalloc’d to the device-reported size; last truncated STRING descriptor with `desc_size == remaining == 4` is a heap OOB. - Two-line, obviously correct check; valid descriptors unaffected. - Bug in this tree’s lineage since ~2014 (v4.9). - Maintainer Greg KH applied v1 after listing maintainers on CC. - No new API/feature; applies cleanly; no prerequisites. AGAINST: - No `Reported-by` / syzbot / crash log. - Author did not answer Greg’s “how tested / how found”. - Greybus is niche; trigger needs hardware. - OOB value is not used to accept the descriptor (still `-EINVAL`). UNRESOLVED: - lore.kernel.org HTTP 403; stable@ search not completed on lore. - No public answer on how the bug was found. **Step 9.2: APPLY THE STABLE RULES CHECKLIST** 1. Obviously correct and tested? **PASS** on correctness by inspection; testing story is thin, but the change is too small to need a complex repro. 2. Fixes a real bug that affects users? **PASS** — OOB on device- supplied manifests for `CONFIG_GREYBUS` users. 3. Important issue? **PASS** — memory-safety / OOB on untrusted hardware data (same bar as USB descriptor checks), not a style nit. 4. Small and contained? **PASS** — +2 lines, one function. 5. No new features or APIs? **PASS**. 6. Can apply to the local tree? **PASS** — file and function exist; patch is already the current code here. **Step 9.3: CHECK FOR EXCEPTION CATEGORIES** Record: Not a device-ID/quirk/DT/docs exception. Ordinary small bugfix. **Step 9.4: MAKE YOUR DECISION** This is a classic stable backport: a long-standing bounds hole in a parser of device-provided descriptors, fixed in two lines with no behavioral change for valid input. Niche hardware lowers blast radius but does not make an OOB read unworthy of stable; USB-style descriptor checks are backported for the same reason. Greg’s unanswered testing question is a quality nit, not a reason to withhold a correct 2-line guard. ### What the commit solves for stable users A Greybus interface enable path copies a hardware manifest into a `kmalloc` buffer and walks descriptors. For `GREYBUS_TYPE_STRING` it used to read `desc->string.length` as soon as the generic 4-byte header was present. If the descriptor claimed only those 4 bytes, that read is past the object (and past the allocation when this is the last remaining bytes). The fix refuses that descriptor via the existing “too small” path. ### Stable rules / risk vs benefit Meets the stable bar: real bug, important (OOB), tiny, no features, applies here. Benefit is closing a memory-safety hole; risk is negligible. ### Concerns No in-the-wild report; discovery method unknown. No extra backport glue needed on this tree. Verification: - [Phase 1] Parsed tags: author SOB, Greg KH SOB, Link to msgid; no Fixes/Reported-by/stable Cc - [Phase 2] Diff: +2 in `identify_descriptor()` STRING case; `break` into existing `desc_size < expected_size` - [Phase 2] Struct sizes from `greybus_manifest.h`: header 4, string fixed 2; `length` at offset 4 - [Phase 2] Pre-image via `git show 18b6510f642db^:drivers/greybus/manifest.c`: length read with no header-size gate - [Phase 3] `git describe HEAD` / Makefile: **v7.3-rc4**, VERSION 7.3.0-rc4 - [Phase 3] `git merge-base --is-ancestor 18b6510f642db HEAD`: yes - [Phase 3] blame: length use from b09c94a1b71c82 (v4.9-rc1); new lines from 18b6510f642dbc - [Phase 3] No Fixes tag; introducing commit in this history - [Phase 3] File log: standalone; later history has no further manifest.c fixes - [Phase 4] `b4 dig -c/-a/-w/-m`: v1 only; maintainers CC’d; Greg asked how found; no NAK; applied 2026-07-17 - [Phase 4] lore.kernel.org WebFetch: **403**; used mbox + openwall/Linaro/lkml.iu.edu - [Phase 4] No author reply to Greg found - [Phase 5] Callers: `gb_manifest_parse` ← `gb_interface_enable` ← module/interface enable; manifest from `gb_control_get_manifest_operation` into `kmalloc(size)` - [Phase 5] semcode: **unavailable**; used grep/read - [Phase 6] Buggy parser present in this tree; apply would be clean - [Phase 7] GREYBUS SUBSYSTEM maintainers: Hovold, Elder, Greg KH - [Phase 8] Failure: heap OOB read, severity HIGH memory-safety / MEDIUM practical crash - UNVERIFIED: stable@ lore discussion (403); exact discovery method (unanswered) **YES** drivers/greybus/manifest.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/greybus/manifest.c b/drivers/greybus/manifest.c index dd7040697bde9..469da3f39afb4 100644 --- a/drivers/greybus/manifest.c +++ b/drivers/greybus/manifest.c @@ -122,6 +122,8 @@ static int identify_descriptor(struct gb_interface *intf, switch (desc_header->type) { case GREYBUS_TYPE_STRING: expected_size += sizeof(struct greybus_descriptor_string); + if (desc_size < expected_size) + break; expected_size += desc->string.length; /* String descriptors are padded to 4 byte boundaries */ -- 2.53.0

1 day, 21 hours

[PATCH v2] greybus: operation: arm the timeout timer before sending the request

by Nguyen Ngoc Thang

gb_operation_request_send() sends the request message and only then arms the operation timer. The host driver can complete the operation before add_timer() runs, e.g. when the transfer fails right away. The completion work then calls timer_delete_sync() on a timer that is not armed yet, the synchronous caller wakes up and drops the last reference, and the operation is freed while the timer is still pending: ODEBUG: free active (active state 0) object type: timer_list hint: gb_operation_timeout+0x0/0xc0 WARNING: lib/debugobjects.c:629 at debug_print_object+0x198/0x2b0 kmem_cache_free+0xfd/0x6d0 gb_operation_sync_timeout+0x1c7/0x270 gb_svc_process_deferred_request+0x5f3/0x1150 Arm the timer before the message is sent. If sending fails, delete the timer again. If it has already fired, its work is queued and drops the active and operation references itself, so the error path must not drop them a second time. Fixes: dbec27298b0d ("staging: greybus: operation: add generic timeout support") Cc: stable(a)vger.kernel.org Reported-by: syzbot+a2e50fb40695811c2dab(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a2e50fb40695811c2dab Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999(a)gmail.com> --- v2: drop the now-unused err_put_active label (-Wunused-label, reported by the kernel test robot). The error path still falls through to it, so the behaviour is unchanged. drivers/greybus/operation.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/greybus/operation.c b/drivers/greybus/operation.c index 7e12ffb2dd60..968a4da5d1d4 100644 --- a/drivers/greybus/operation.c +++ b/drivers/greybus/operation.c @@ -766,18 +766,22 @@ int gb_operation_request_send(struct gb_operation *operation, if (ret) goto err_put; - ret = gb_message_send(operation->request, gfp); - if (ret) - goto err_put_active; - + /* Arm before sending, as the response may complete the operation at once. */ if (timeout) { operation->timer.expires = jiffies + msecs_to_jiffies(timeout); add_timer(&operation->timer); } + ret = gb_message_send(operation->request, gfp); + if (ret) + goto err_del_timer; + return 0; -err_put_active: +err_del_timer: + /* A timer that already fired has queued work which drops our references. */ + if (timeout && !timer_delete_sync(&operation->timer)) + return ret; gb_operation_put_active(operation); err_put: gb_operation_put(operation); -- 2.43.0

1 day, 22 hours

[PATCH v3] greybus: operation: close the race between completion and arming the timer

by Nguyen Ngoc Thang

gb_operation_request_send() sends the request message and only then arms the operation timer. The host driver can complete the operation before add_timer() runs, e.g. when the transfer fails right away. The completion work then calls timer_delete_sync() on a timer that is not armed yet, the synchronous caller returns and drops the last reference, and the operation is freed while the timer is pending: ODEBUG: free active (active state 0) object type: timer_list hint: gb_operation_timeout+0x0/0xc0 WARNING: lib/debugobjects.c:629 at debug_print_object+0x198/0x2b0 kmem_cache_free+0xfd/0x6d0 gb_operation_sync_timeout+0x1c7/0x270 gb_svc_process_deferred_request+0x5f3/0x1150 Keep sending the request first, so a request that is cancelled or times out is always one that has been submitted. Instead, hold an extra reference until the timer is armed, and delete the timer again if the operation has completed by then, since the completion work could not have seen it. Fixes: dbec27298b0d ("staging: greybus: operation: add generic timeout support") Cc: stable(a)vger.kernel.org Reported-by: syzbot+a2e50fb40695811c2dab(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a2e50fb40695811c2dab Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999(a)gmail.com> --- Changes in v3 (after Johan's review): - Do not reorder send and add_timer, so a cancelled or timed-out request has always been submitted. Hold an extra reference until the timer is armed and delete the timer if the operation already completed. - Retested with the syzbot C reproducer in QEMU (DEBUG_OBJECTS_TIMERS): 5 ODEBUG warnings per run before, none in 3/3 runs after. - v1/v2 armed the timer before sending the message and are dropped. drivers/greybus/operation.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/greybus/operation.c b/drivers/greybus/operation.c index 7e12ffb2dd60..f3a65e693133 100644 --- a/drivers/greybus/operation.c +++ b/drivers/greybus/operation.c @@ -766,18 +766,28 @@ int gb_operation_request_send(struct gb_operation *operation, if (ret) goto err_put; + /* The completion can drop the other references before the timer is armed. */ + gb_operation_get(operation); + ret = gb_message_send(operation->request, gfp); if (ret) - goto err_put_active; + goto err_put_send; if (timeout) { operation->timer.expires = jiffies + msecs_to_jiffies(timeout); add_timer(&operation->timer); + + /* A completion that already ran did not see the timer. */ + smp_mb(); + if (READ_ONCE(operation->errno) != -EINPROGRESS) + timer_delete_sync(&operation->timer); } + gb_operation_put(operation); return 0; -err_put_active: +err_put_send: + gb_operation_put(operation); gb_operation_put_active(operation); err_put: gb_operation_put(operation); -- 2.43.0

1 day, 22 hours

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev October 2026