A security vulnerability has been detected in Linux Foundation Magma 1.9.0. Affected by this vulnerability is an unknown functionality of the file tasks/ngap/ngapamf.c of the component gNB Termination Handler. The manipulation leads to denial of service. The attack is possible to be carried out remotely. The exploit has been disclosed publicly and may be used.

A weakness has been identified in Linux Foundation Magma 1.9.0. Affected is an unknown function of the file ngapamfhandlers.c of the component NGSetup Handler. Executing a manipulation can lead to state issue. The attack can be executed remotely. The exploit has been made available to the public and could be used for attacks.

A security flaw has been discovered in Linux Foundation Magma 1.9.0. This impacts an unknown function of the component NGSetupRequest Handler. Performing a manipulation of the argument NG-IoT-DefaultPagingDRX results in improper input validation. Remote exploitation of the attack is possible. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.

A vulnerability was identified in Linux Foundation Magma 1.9.0. This affects an unknown function of the component SecurityModeComplete Handler. Such manipulation leads to improper validation of integrity check value. The attack may be launched remotely. The exploit is publicly available and might be used.

A vulnerability was determined in Linux Foundation Magma 1.9.0. The impacted element is an unknown function of the component InitialUEMessage Handler. This manipulation causes information disclosure. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized.

A vulnerability was found in Linux Foundation Magma 1.9.0. The affected element is an unknown function of the file tasks/amf/amffsm.cpp of the component Registration Complete Message Handler. The manipulation results in improper authentication. The attack can be launched remotely. The exploit has been made public and could be used.

Latest version: 1.21.1

In the Linux kernel, the following vulnerability has been resolved:

net/sched: actapi: use RCU with deferred freeing for action lifecycle

When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action.

Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:

0: mutexlock() <-- holds the idr lock 0: rcureadlock() 0: p = idrfind(idr, index) <-- action p is valid (RCU protects IDR) 0: mutexunlock() <-- releases the idr lock 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) <-- Action removed from IDR 1: mutexunlock() <-- mutex released allowing us to delete the action 1: tcfactioncleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcountincnotzero(&p->tcfarefcnt) <-- ouch, UAF p points to freed memory

This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcuhead to tcaction used in the deferral and introducing a callrcu() in the delete path to defer the final kfree().

Note: this is a revert of commit d7fb60b9cafb ("netsched: get rid of tcfarcu") but also modernization/simplification to directly use kfreercu().

Let's illustrate the new restored code path:

0: rcureadlock() 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) 1: mutexunlock() 1: callrcu(&p->tcfarcu, tcfactionrcufree) <-- defer kfree after grace period 0: p = idrfind(idr, index) 0: refcountincnotzero(&p->tcfarefcnt) <-- fails, refcnt already 0 1: rcureadunlock() <-- release so freeing can run after grace period

After CPU1 calls idrremove(), the object is no longer reachable through the IDR. CPU0's subsequent idrfind() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.

bnxten: Fix NULL pointer dereference

In the Linux kernel, the following vulnerability has been resolved:

fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal

CXL is linked before fwctl in drivers/Makefile. Both use moduleinit, so cxlpcidriverinit() runs first. When cxlpciprobe() calls fwctlregister() and then deviceadd(), fwctlclass is not yet registered because fwctlinit() hasn't run, causing classtosubsys() to return NULL and skip knodeclass initialization.

On device removal, classtosubsys() returns non-NULL, and devicedel() calls klistdel() on the uninitialized knode, triggering a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ebtables: fix OOB read in compatmtwfromuser

Luxiao Xu says:

The function compatmtwfromuser() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied matchsize/targetsize.

When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN.

This fix introduces a check to ensure matchsize is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets.

AFAIU this is relevant for matches that need to go though match->compatfromuser() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace).

The ->compatfromuser() callbacks assume they can read compatsize bytes, so they need this extra check.

Based on an earlier patch from Luxiao Xu.

In the Linux kernel, the following vulnerability has been resolved:

tun: free page on buildskb failure in tunxdpone()

When buildskb() fails in tunxdpone(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhostnetbuildxdp() allocated for the frame. As with the short-frame rejection path, tunsendmsg() discards the per-buffer error and still returns totallen, so vhosttxbatch() takes the success path and never frees the page. Each buildskb() failure in a batch leaks one page-frag chunk.

Free the page before taking the error path, matching the putpage() the other error exits of tunxdpone() already perform.

In the Linux kernel, the following vulnerability has been resolved:

media: iris: Fix use-after-free in irisreleaseinternalbuffers()

The recent change in commit 1dabf00ee206 ("media: iris: gen1: Destroy internal buffers after FW releases") introduced a regression where sessionreleasebuf() may free the buffer. The caller, irisreleaseinternalbuffers(), continued to access buffer after the call, leading to a potential use-after-free.

Fix this by setting BUFATTRPENDINGRELEASE before calling sessionreleasebuf(), and reverting the flag if the call fails. This ensures no dereference occurs after potential freeing.

In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Fix dma-buf attachment leak in xegemprimeimport()

When xedmabufinitobj() fails, the attachment from dmabufdynamicattach() is not detached. Add dmabufdetach() before returning the error. Note: we cannot use goto outerr here because xedmabufinitobj() already frees bo on failure, and outerr would double-free it.

(cherry picked from commit a828eb185aac41800df8eae4b60501ccc0dbbe51)

In the Linux kernel, the following vulnerability has been resolved:

wifi: rsi: fix kthread lifetime race between self-exit and external-stop

RSI driver use both self-exit(kthreadcompleteandexit) and external-stop (kthreadstop) when killing a kthread. Generally, kthreadstop() is called first, and in this case, no particular issues occur.

However, in rare instances where kthreadcompleteandexit() is called first and then kthreadstop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again.

Therefore, to prevent this with minimal modification, you must remove kthreadstop() and change the code to wait until the self-exit operation is completed.

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btmtk: validate WMT event SKB length before struct access

btmtkusbhciwmtsync() casts the WMT event response SKB data to struct btmtkhciwmtevt (7 bytes) and struct btmtkhciwmtevtfuncc (9 bytes) without first checking that the SKB contains enough data. A short firmware response causes out-of-bounds reads from SKB tailroom.

Use skbpulldata() to validate and advance past the base WMT event header. For the FUNCCTRL case, pull the additional status field bytes before accessing them.

In the Linux kernel, the following vulnerability has been resolved:

powerpc/xive: fix kmemleak caused by incorrect chipdata lookup

The kmemleak reports the following memory leak:

Unreferenced object 0xc0000002a7fbc640 (size 64): comm "kworker/8:1", pid 540, jiffies 4294937872 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 09 04 00 04 00 00 ................ 00 00 a7 81 00 00 0a c0 00 00 08 04 00 04 00 00 ................ backtrace (crc 177d48f6): kmalloccachenoprof+0x520/0x730 xiveirqallocdata.constprop.0+0x40/0xe0 xiveirqdomainalloc+0xd0/0x1b0 irqdomainallocirqsparent+0x44/0x6c pseriesirqdomainalloc+0x1cc/0x354 irqdomainallocirqsparent+0x44/0x6c msidomainalloc+0xb0/0x220 irqdomainallocirqslocked+0x138/0x4d0 irqdomainallocirqs+0x8c/0xfc msidomainallocirqs+0x214/0x4d8 msidomainallocirqsalllocked+0x70/0xf8 pcimsisetupmsiirqs+0x60/0x78 pcienablemsixrange+0x54c/0x98c pciallocirqvectorsaffinity+0x16c/0x1d4 nvmepcienable+0xac/0x9c0 [nvme] nvmeprobe+0x340/0x764 [nvme]

This occurs when allocating MSI-X vectors for an NVMe device. During allocation the XIVE code creates a struct xiveirqdata and stores it in irqdata->chipdata.

When the MSI-X irqdomain is later freed, xiveirqfreedata() is responsible for retrieving this structure and freeing it. However, after commit cc0cc23babc9 ("powerpc/xive: Untangle xive from child interrupt controller drivers"), xiveirqfreedata() retrieves the chipdata using irqgetchipdata(), which looks up the data through the child domain.

This is incorrect because the XIVE-specific irq data is associated with the XIVE (parent) domain. As a result the lookup fails and the allocated struct xiveirqdata is never freed, leading to the kmemleak report shown above.

Fix this by retrieving the irqdata from the correct domain using irqdomaingetirqdata() and then accessing the chipdata via irqdatagetirqchipdata().

Bluetooth: hciconn: fix potential UAF in createbigsync

In the Linux kernel, the following vulnerability has been resolved:

of: unittest: fix use-after-free in testdrvprobe()

The function testdrvprobe() retrieves the devicenode from the PCI device, applies an overlay, and then immediately calls ofnodeput(dn). This releases the reference held by the PCI core, potentially freeing the node if the reference count drops to zero. Later, the same freed pointer 'dn' is passed to ofplatformdefaultpopulate(), leading to a use-after-free.

The reference to pdev->dev.ofnode is owned by the device model and should not be released by the driver. Remove the erroneous ofnodeput() to prevent premature freeing.

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix memory leak in amdgpuacpienumeratexcc()

In amdgpuacpienumeratexcc(), if amdgpuacpidevinit() returns -ENOMEM, the function returns directly without releasing the allocated xccinfo, resulting in a memory leak.

Fix this by ensuring that xccinfo is properly freed in the error paths.

Compile tested only. Issue found using a prototype static analysis tool and code review.

In the Linux kernel, the following vulnerability has been resolved:

usb: cdns3: fix role switching during resume

If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference.

The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped.

So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode.

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhcdisprimaryhcd+0x0/0x1c lr : cdnshostresume+0x24/0x5c ... Call trace: usbhcdisprimaryhcd+0x0/0x1c (P) cdnsresume+0x6c/0xbc cdns3controllerresume.isra.0+0xe8/0x17c cdns3platresume+0x18/0x24 platformpmresume+0x2c/0x68 dpmruncallback+0x90/0x248 deviceresume+0x100/0x24c dpmresume+0x190/0x2ec dpmresumeend+0x18/0x34 suspenddevicesandenter+0x2b0/0xa44 pmsuspend+0x16c/0x5fc statestore+0x80/0xec kobjattrstore+0x18/0x2c sysfskfwrite+0x7c/0x94 kernfsfopwriteiter+0x130/0x1dc vfswrite+0x240/0x370 ksyswrite+0x70/0x108 arm64syswrite+0x1c/0x28 invokesyscall+0x48/0x10c el0svccommon.constprop.0+0x40/0xe0 doel0svc+0x1c/0x28 el0svc+0x34/0x108 el0t64synchandler+0xa0/0xe4 el0t64sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:

phy: freescale: imx8qm-hsio: fix NULL pointer dereference

During the probe the refclkpad pointer is set to NULL if the 'fsl,refclk-pad-mode' property is not defined in the devicetree node. But in imxhsioconfigureclkpad() this pointer is unconditionally used which could result in a NULL pointer dereference. So check the pointer before to use it.

In the Linux kernel, the following vulnerability has been resolved:

net: remove WARNONONCE when accessing forward path array

Although unlikely, recent support for IPIP tunnels increases chances of reaching this WARNONONCE if userspace manages to build a sufficiently long forward path.

Remove it.

Also the entire nonsense about making the found issues public - this is absurd and just exacerbates the asymmetry problem.

By keeping the reports private, the OSS teams can deal with the issues more on their timeline.

By making them public, they add timeline pressure and enable attackers.

Why are you making it harder on yourself?  It is the opposite of what you want to do.

If it's giving CVE credit to people who've taken the time and tokens to report these issues that concerns you, than just bundle the issues in one CVE.

ROI AI

From: ROI AI <sales () roiai ca> To: "oss-security"<oss-security () lists openwall com> Date: Wed, 20 May 2026 22:26:21 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age

People are shooting the messengers here.   The fact is - we are going through a generational security event due to the advancement of LLMs.

It is also both trivial and extremely effective to use Agentic analysis to filter security reports.

As for 'duplicates', people are claiming this when I have seen little evidence.  I reported a dozen or so to one major project and no one has yet claimed invalid or duplicate.

Moreover, if 'duplicates' are found, then that is a good signal for prioritization.

Let's stop talking about how the vulns are found and start fixing them with urgency.

ROI AI

From: Alan Coopersmith < mailto:alan.coopersmith () oracle com > To: < mailto:oss-security () lists openwall com > Date: Wed, 20 May 2026 10:52:37 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age

On 4/28/26 07:58, Jeremy Stanley wrote: I'm sorely tempted, both due to the increased volume and the risk of premature disclosure, to just assume that any vulnerability reported as a result of research using an LLM is trivially discoverable by others, and give up trying to pretend there's any point to working it under embargo. Other maintainers under similar floods seem to agree: Linux kernel: - https://lkml.org/lkml/2026/5/17/896 - https://docs.kernel.org/process/security-bugs.html DNS servers (BIND, Unbound, PowerDNS): - https://indico.dns-oarc.net/event/56/contributions/1233/ - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf -- -Alan Coopersmith- mailto:alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.

On 4/28/26 07:58, Jeremy Stanley wrote: Other maintainers under similar floods seem to agree:

Linux kernel: - https://lkml.org/lkml/2026/5/17/896 - https://docs.kernel.org/process/security-bugs.html

DNS servers (BIND, Unbound, PowerDNS): - https://indico.dns-oarc.net/event/56/contributions/1233/ - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

In the Linux kernel, the following vulnerability has been resolved:

nvme-pci: Fix race bug in nvmepollirqdisable()

In the following scenario, pdev can be disabled between (1) and (3) by (2). This sets pdev->msixenabled = 0. Then, pciirqvector() will return MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2). This causes IRQ warning because it tries to enable INTx IRQ that has never been disabled before.

To fix this, save IRQ number into a local variable and ensure disableirq() and enableirq() operate on the same IRQ number. Even if pcifreeirqvectors() frees the IRQ concurrently, disableirq() and enableirq() on a stale IRQ number is still valid and safe, and the depth accounting reamins balanced.

task 1: nvmepollirqdisable() disableirq(pciirqvector(pdev, nvmeq->cqvector)) ...(1) enableirq(pciirqvector(pdev, nvmeq->cqvector)) ...(3)

task 2: nvmeresetwork() nvmedevdisable() pdev->msixenable = 0; ...(2)

crash log:

------------[ cut here ]------------ Unbalanced enable for IRQ 10 WARNING: kernel/irq/manage.c:753 at enableirq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26 Modules linked in: CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blkmqtimeoutwork RIP: 0010:enableirq+0x107/0x190 kernel/irq/manage.c:753 Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9 RSP: 0018:ffffc900001bf550 EFLAGS: 00010046 RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90 RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0 RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000 R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293 FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0 Call Trace: <TASK> enableirq+0x121/0x1e0 kernel/irq/manage.c:797 nvmepollirqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvmetimeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blkmqrqtimedout block/blk-mq.c:1653 [inline] blkmqhandleexpired+0x227/0x2d0 block/blk-mq.c:1721 btiter+0x2fc/0x3a0 block/blk-mq-tag.c:292 sbitmapforeachset include/linux/sbitmap.h:269 [inline] sbitmapforeachset include/linux/sbitmap.h:290 [inline] btforeach block/blk-mq-tag.c:324 [inline] blkmqqueuetagbusyiter+0x969/0x1e80 block/blk-mq-tag.c:536 blkmqtimeoutwork+0x627/0x870 block/blk-mq.c:1763 processonework+0x956/0x1aa0 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 retfromfork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246 </TASK> irq event stamp: 74478 hardirqs last enabled at (74477): [<ffffffffb5720a9c>] rawspinunlockirq include/linux/spinlockapismp.h:159 [inline] hardirqs last enabled at (74477): [<ffffffffb5720a9c>] rawspinunlockirq+0x2c/0x60 kernel/locking/spinlock.c:202 hardirqs last disabled at (74478): [<ffffffffb57207b5>] rawspinlockirqsave include/linux/spinlockapismp.h:108 [inline] hardirqs last disabled at (74478): [<ffffffffb57207b5>] rawspinlockirqsave+0x85/0xa0 kernel/locking/spinlock.c:162 softirqs last enabled at (74304): [<ffffffffb1e9466c>] dosoftirq kernel/softirq.c:656 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] invokesoftirq kernel/softirq.c:496 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] irqexitrcu+0xdc/0x120 ---truncated---

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: ftcm: Fix NULL pointer dereferences in nexus handling

The tpg->tpgnexus pointer in the USB Target driver is dynamically managed and tied to userspace configuration via ConfigFS. It can be NULL if the USB host sends requests before the nexus is fully established or immediately after it is dropped.

Currently, functions like botsubmitcommand() and the data transfer paths retrieve tvnexus = tpg->tpgnexus and immediately dereference tvnexus->tvnsesess without any validation. If a malicious or misconfigured USB host sends a BOT (Bulk-Only Transport) command during this race window, it triggers a NULL pointer dereference, leading to a kernel panic (local DoS).

This exposes an inconsistent API usage within the module, as peer functions like usbgsubmitcommand() and botsendbadresponse() correctly implement a NULL check for tvnexus before proceeding.

Fix this by bringing consistency to the nexus handling. Add the missing if (!tvnexus) checks to the vulnerable BOT command and request processing paths, aborting the command gracefully with an error instead of crashing the system.

In the Linux kernel, the following vulnerability has been resolved:

sched/mmcid: Handle vfork()/CLONEVM correctly

Matthieu and Jiri reported stalls where a task endlessly loops in mmgetcid() when scheduling in.

It turned out that the logic which handles vfork()'ed tasks is broken. It is invoked when the number of tasks associated to a process is smaller than the number of MMCID users. It then walks the task list to find the vfork()'ed task, but accounts all the already processed tasks as well.

If that double processing brings the number of to be handled tasks to 0, the walk stops and the vfork()'ed task's CID is not fixed up. As a consequence a subsequent schedule in fails to acquire a (transitional) CID and the machine stalls.

Cure this by removing the accounting condition and make the fixup always walk the full task list if it could not find the exact number of users in the process' thread list.

In the Linux kernel, the following vulnerability has been resolved:

hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read

The q54sj108a2debugfsread function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'datachar' as the source.

Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2CSMBUSBLOCKMAX + 2), this writes 30 bytes past the end of the buffer onto the stack.

Additionally, the arguments were swapped: it was reading from the zero-initialized 'datachar' and writing to 'data', resulting in all-zero output regardless of the actual I2C read.

Fix this by: 1. Expanding 'datachar' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simplereadfrombuffer call.