# Unbounded count in memx\_fops\_read copy\_to\_user — possible kernel memory disclosure **URL:** \ **Category:** General\ **Created:** [June 14, 2026, 4:26am UTC](https://community.memryx.com/t/unbounded-count-in-memx-fops-read-copy-to-user-possible-kernel-memory-disclosure/220 "2026-06-14T04:26:18Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![scyto](https://avatars.discourse-cdn.com/v4/letter/s/dc4da7/32.png) [@scyto](https://community.memryx.com/u/scyto)\ **Post date:** [June 14, 2026, 4:26am UTC](https://community.memryx.com/t/unbounded-count-in-memx-fops-read-copy-to-user-possible-kernel-memory-disclosure/220/1 "2026-06-14T04:26:18Z")
_Ok i am going to be super clear, i am not a programmer, i have worked in software for 20 years including security enviroments that include TLA. So when i see an AI unsolicitedly tell me it found a potential buffer ovelow i am both sketpical but pay attenttion. The text below is claudes analysis after i pushed it several time to make sure i dont end up looking stupid for speaking up. I would prefer to look stupid than not pass on a real issue. So with that…_ * * * Flagging a possible out-of-bounds read in the PCIe driver’s read path. Up front: I found this with AI-assisted analysis while looking at an unrelated logging change, and I haven’t exploited it or fully traced the userspace side, so please treat it as something to verify against the intended `read()` contract rather than a confirmed CVE. In `kdriver/linux/pcie/memx_cascade_pciemain.c`, `memx_fops_read()` copies the user-supplied `count` directly: ```c if (copy_to_user((void __user *)buf, memx_dev->mpu_data.rx_dma_coherent_buffer_virtual_base, count)) { ``` `count` comes straight from `read(2)` and isn’t bounded against the source buffer. That buffer is a single ~2 MB `kzalloc` allocation (`DMA_COHERENT_BUFFER_SIZE_2MB + cache_line_size()`), of which a real output map is at most 512 KB. A `read()` with `count` larger than the allocation copies adjacent kernel memory out to userspace until `copy_to_user` faults, leaking kernel heap contents (kernel pointers, etc.). The reason I think it’s worth a look rather than purely theoretical: the device node is created `0666` (`DEVICE_NODE_DEFAULT_ACCESS_RIGHT`), so any local user can open it, and the copy is reachable after a normal inference completes. The same pattern is in the `32bit_driver/` copy. Normal SDK use does appear bounded — the in-repo Python wrapper sizes its reads from `memx_get_ofmap_size()`, and the demo test app reads a fixed 4 bytes — so legitimate traffic shouldn’t trip this. But the actual `read()` call lives inside the closed `libmemx.so` (no source in the repo, only the ARM32 blob), so I couldn’t confirm the syscall-level `count` directly. And it doesn’t really matter where the bound is: with a `0666` node, an unprivileged process can bypass the SDK entirely and pass an arbitrary `count` straight to the syscall, so the kernel shouldn’t rely on userspace to bound it. Suggested fix is to reject or clamp before the copy, e.g.: ```c if (count > OFMAP_EGRESS_DCORE_DMA_COHERENT_BUFFER_SIZE_512KB) return -EINVAL; ``` or clamp to the actual payload length the header already exposes (the total-length field read at buffer offset 12). Tightening the node would help as defense in depth, but note it isn’t a drop-in change: the `devnode` callback only sets the mode, so the node comes up `root:root`, and going to `0660` without also assigning a group would lock out non-root processes (including a containerized Frigate). Doing it properly means a dedicated group, a udev rule to set group ownership, and adding the service account to that group — the usual `render`/`video` pattern. Given that, the `count` clamp is the more important and self-contained fix. ---
**Author:** ![mx-tim](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.memryx.com/mx-tim/32/62_2.png) [@mx-tim](https://community.memryx.com/u/mx-tim)\ **Post date:** [June 15, 2026, 7:13pm UTC](https://community.memryx.com/t/unbounded-count-in-memx-fops-read-copy-to-user-possible-kernel-memory-disclosure/220/2 "2026-06-15T19:13:45Z")
Interesting stuff, I’ll share this with our driver team and we might use that patch. It’s right that libmemx.so does do its own checking, but by making the device node 0666 by default, `memx_fops_read` (=`read`file operation) can be called by a malicious application to read beyond the buffer size by setting a very large `count`. It also seems like clamping count to the max buffer size will prevent this out of bounds access. So we’ll take and look and release an update if confirmed. Thanks for finding this!