greybus-dev October 2026

greybus-dev@lists.linaro.org

28 participants
38 discussions

[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

5 hours, 19 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

16 hours, 32 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

17 hours, 57 minutes

[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

19 hours, 5 minutes

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

by Haasham Khan

20 hours, 19 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, 19 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, 19 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, 20 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, 20 hours

[PATCH] staging: greybus: fw-management: fix argument alignment

by Okhuomon Ajayi

Align the arguments of the fw_mgmt_load_and_validate_operation() call with the opening parenthesis and split them across separate lines to avoid an overly long line. CHECK: Alignment should match open parenthesis Signed-off-by: Okhuomon Ajayi <okhuomonajayi54(a)gmail.com> --- drivers/staging/greybus/fw-management.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/greybus/fw-management.c b/drivers/staging/greybus/fw-management.c index 5d01da6b6eb9..e20e9136c106 100644 --- a/drivers/staging/greybus/fw-management.c +++ b/drivers/staging/greybus/fw-management.c @@ -434,7 +434,8 @@ static int fw_mgmt_ioctl(struct fw_mgmt *fw_mgmt, unsigned int cmd, return -EFAULT; ret = fw_mgmt_load_and_validate_operation(fw_mgmt, - intf_load.load_method, intf_load.firmware_tag); + intf_load.load_method, + intf_load.firmware_tag); if (ret) return ret; -- 2.43.0

1 day, 21 hours

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

greybus-dev October 2026