From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 398772D9ECB for ; Fri, 19 Jun 2026 02:36:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781836576; cv=none; b=kKhfMiuJCeNd0oOnvTtX/23SfyAbe3QW1zvnQ8UHPbdBNmkK81VDddEgbqJU3CrL8DM7/NvqKakc3cG16ko3TjdL6YBxxnkLfYq3O2cHEpFm74BZib67N/byYOk4o99awivxYuo1AtS5xxVkEH+fOKtrVGuE8wBGasTVG8BgaQE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781836576; c=relaxed/simple; bh=uLJXlYx7wcOWsPeFy9gNmfIk9XvzdJeo7mJlUDmtkdA=; h=From:To:Cc:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Q8nMI5No0tUWrFHDQvxShmmTK3jFOZpWo5VbFd/D72qM73gr5jTvAjK1ox+YWgNIYbAjiDdTYqDJqM8vek0Tqv9UbweMTrAKFatbztuMdPmnKf4N+JTZpQvH/e55UeHPOPLo1o1ePBp70YL+wIlT8kjbMuSpcvVG0z3VER6UBkU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Q+VKQ7gz; arc=none smtp.client-ip=209.85.210.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Q+VKQ7gz" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-84231305a80so940195b3a.0 for ; Thu, 18 Jun 2026 19:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781836574; x=1782441374; darn=vger.kernel.org; h=mime-version:content-transfer-encoding:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=XHqEORpslI1FT63Z8ElNeWMRAg3ec3xTp1z9QP8/uho=; b=Q+VKQ7gzD9L1BADbRMaiCzSniPsQoK94AJ/zhFeIeCBxY3519zDPaptfg35+VbnavI IPjpbBjqJpo5wMGRb6DM4CwuHrFq5iMGR1qUvQKhhRvOJ0WEk9pDV8q0PXJrTh26TT7r sU3auo/jXx2EE9RLP+2kQ3G+vRr/DGmFJwb49sJR629BhD0Z7xY0FJqYSz4HvjTAPdYk O8No9kH1ILdL1etFBWUqd4uanz02UmnrI/R5wJc+CxAaObT6O323u1dflA7BOWljLZUY Bzi9dC1c8SdB6qDNzjkw9tcEmQmG5dF941D9C/lfUAXPWpy5aTKEclCL1mTxNN8oS8Yd EyHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781836574; x=1782441374; h=mime-version:content-transfer-encoding:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XHqEORpslI1FT63Z8ElNeWMRAg3ec3xTp1z9QP8/uho=; b=DWrup30LoNJDe+M9WDjPUTHodHlyuDDiRsHDK54VnlquzhxNDF85ZkILolFCVeH2Zi iU3kvGQKWueNEbQsbICrfl+4r+wYJNHs8hxOZv92phfLOlf5xOAAxjqSbg34/Yp/wLyN DdbzKAUyW3k7X5TmSGbnAsvGF+v4yRSGG85Y9TVtrAY2qe/ag6Yg2pjfJcvzPlA3mtIo o6T9w3sInvud3CuNCpxDNgBYUDTEEnoEqMkWttfuDz5GOd/GJgTeJc4hCfahN2A+cqFW /ymFUfzN6UIdTtxe8b8BkJwL4WRcxT/btzOvAda7/vv6lvAjU5mpW8OMYtNHfU78M9ag Y4MQ== X-Forwarded-Encrypted: i=1; AFNElJ8mhIGJvTctr1CKp1rtGVeab+I0NkuQbKB7/mbAAspNluvxb0C6FG1+dX25dbuqqoXn7uuk1L4Ss58J5Qg=@vger.kernel.org X-Gm-Message-State: AOJu0YzyZMAQ75iBn+l15XTbdswvRDz+oVGU4aOh43dYxbqxHIGvr/72 CgX92N74UaHxNK723q3KUbqB0gTf1Xmsu4A1PjIDkXqmIaFJTG+a7iI5Rxho8A== X-Gm-Gg: AfdE7clvbs8N23XXxSYXNvnEAV4K8aVdFQuSsDP/Qwgq+YA5rcHZ9WHj9CRZNLkSJ4k qrKZBte1wu2WihtpR2uVl6o1HvUoD/D2p8eEjRXTgdA3WCF8Dolu/xc0GA4oxHkT64Jbizn42hM bCOY6nrWJKK0DdVYhGCF8b47lSegNQtlxd0Iq8Q/lIN+Dm4tJ8rzP5BEbXzVUqYTCsUGhq/HsRp idk34BAY3GFM0Ge/eGUcEehiwltNNaUbtGn7uUCJQEQYFr87uZfWF3+1uw0638VpiPudzgIA8K1 oav+MHvrriYvS/e9bnNNe2yycID3hsVGasJC0C6jiFS7tx8m/INLuGDh96URP/gh0Aag1cTGF7r RwPXf8JtFmOQGIdXyX5cAfMuaNcEmNr456KbPBYl7SFFUVoS8Uw3d9mq2ZWHrYaQr44A2EEUb7D arlIq+f70NJro40vjazGAGwxZsNri1y/xeYPG6vQ== X-Received: by 2002:a05:6a00:4f96:b0:842:77ab:35df with SMTP id d2e1a72fcca58-8455079fd98mr1677838b3a.11.1781836574505; Thu, 18 Jun 2026 19:36:14 -0700 (PDT) Received: from csl-conti-dell7858.ntu.edu.sg ([155.69.195.57]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-845537fa674sm530464b3a.33.2026.06.18.19.36.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jun 2026 19:36:13 -0700 (PDT) From: Maoyi Xie To: Vaibhav Agarwal , Mark Greer Cc: Johan Hovold , Alex Elder , Greg Kroah-Hartman , greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: staging: greybus: audio: possible out of bounds read in the topology parser Date: Fri, 19 Jun 2026 10:36:10 +0800 Message-ID: <178183657058.3862365.12892304946786698397@maoyixie.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi all, I think the Greybus audio topology parser in drivers/staging/greybus/audio_topology.c can read past the topology blob when a module reports inconsistent counts. I would appreciate it if you could take a look. gb_audio_gb_get_topology() allocates the blob to a device-reported u16 size and only checks that it is at least sizeof(struct gb_audio_topology). size = le16_to_cpu(size_resp.size); if (size < sizeof(*topo)) return -ENODATA; topo = kzalloc(size, GFP_KERNEL); After that the parser trusts the interior fields. gb_generate_enum_strings() walks one C string per item with no end pointer. items = le32_to_cpu(gbenum->items); for (i = 0; i < items; i++) { strings[i] = data; while (*data != '\0') data++; data++; } items is a device le32 and there is no guarantee the blob holds that many NUL terminated strings, so the while loop runs off the end of the allocation. The same pattern is in gbaudio_tplg_process_header(), which derives the control, widget and route offsets by adding device le32 block sizes with no check against the end of the blob, and in the csize cursor advance in gbaudio_tplg_process_kcontrols() and gbaudio_tplg_create_widget(). The whole blob is device data parsed on the probe path with no privilege needed. The attacker here is a malicious or faulty Greybus audio module on the interface. I reproduced the enum string walk under KASAN on 7.1-rc7. A blob with one NUL per item stays inside the allocation. A blob with missing terminators makes KASAN report a slab out of bounds read past the buffer. I have a partial fix that passes the buffer end into the enum walk and stops on overrun. A complete fix also needs to bound the header offsets and the csize advances against the allocation size, so I wanted to ask before sending a series. Does this look like a real bug to you? If it does I am happy to send a proper patch. The parser was added in c8e6336bb3f8 ("greybus: audio: Add topology parser for GB codec"), which I think is the right Fixes tag. Thanks, Maoyi https://maoyixie.com/