Xen and dom0 probably okay.
Malloc is bad which affects all guest OS. AppVM uses same bad malloc bug on AppVM2 by sending bad input to appVM2. Keystrokes leave the PC.
Malloc bad. Need qubesos design done at malloc process level in OS level.
The security architecture of QubesOS is not about guest operating systems in virtual machines (VMs), but about the boundaries between them (add some hardware abstraction here). I’d ask you again to read the documentation. It seems like you didn’t get much about the concept of compartmentalisation.
I understand fully.
QubesOS is not secure because malloc is not secure. Activity in a VM is not isolated because the VM’s talk to each other.
If the VM’s didn’t talk to each other, then can’t use internet. But thats not practical.
Malloc needs to be fixed with a QubesOS design done at the malloc process level. Isolated processes. With their own memory, that other processes can not touch.
ChatGPT 5.6 sol on xhigh (pro)
Prompt: in one paragraph - does MasterQube have a point?
Only at the broadest level: MasterQube is right that hostile inputs, memory-safety bugs, and vulnerable cross-domain parsers are genuine attack surfaces, and a hardened allocator can make some heap exploits harder; however, his central diagnosis is technically wrong. malloc merely parcels out memory within a process’s existing virtual address space—process protection is enforced by CPU page tables and the OS—while Qubes adds a separate Xen-enforced boundary between VMs. Qubes do communicate, but through deliberately exposed, controlled mechanisms such as policy-mediated qrexec/vchan and capability-based Xen grant tables, not by freely reading one another’s allocations; having internet connectivity likewise does not imply arbitrary VM-to-VM memory access. So his useful point is simply that memory safety and trusted communication interfaces deserve hardening, whereas “Qubes is insecure because malloc is insecure” and “reimplement Qubes at the malloc level” conflate allocator safety with process and VM isolation and would not solve the problem he describes.
2 Likes
ask it how to break out of a processes’ virtual address space and access other other processes address space
Well it wont give me a working exploit sadly 
But here is the answer:
ChatGPT 5.6 sol on xhigh (pro)
You cannot “break out” of a process’s virtual address space with malloc alone. The CPU translates every user-space address through the page tables assigned to the currently running process. An arbitrary pointer produced by a heap bug is therefore interpreted only within that process’s mappings; it cannot name another process’s private memory.
Another process’s memory becomes accessible only through one of these routes:
-
An authorized kernel interface. Linux provides debugging and inspection mechanisms such as
ptrace(),process_vm_readv()/writev(), and/proc/<pid>/mem. These do not bypass virtual-memory isolation—the kernel performs the transfer after checking credentials, dumpability, security-module policy, and capabilities such asCAP_SYS_PTRACE. -
Intentionally shared memory or IPC. Two processes may explicitly map the same pages or exchange data through sockets, pipes, files, or another broker. That is controlled communication, not one process escaping into another address space.
-
Compromise of the component enforcing the boundary. An attacker who has already obtained code execution in one process would need an additional kernel, driver, privileged-service, or similar vulnerability to gain the authority to inspect or modify other processes.
So a heap vulnerability can expose arbitrary memory inside the vulnerable process and possibly give code execution with that process’s privileges. It does not automatically expose another process. The necessary next step would be a distinct privilege-escalation or IPC-boundary vulnerability.
The same distinction applies one level higher in Qubes OS: networking or qrexec communication passes selected data between isolated compartments; it does not merge their address spaces. Crossing from one qube into another requires a separate failure in Xen or another exposed cross-domain component. Qubes explicitly uses virtualization to isolate applications and system components, and ordinary inter-qube networking is prohibited unless deliberately enabled.
A forum-ready answer would be:
You do not break out of a process’s virtual address space through
malloc. The CPU and kernel already give each process separate page tables, so even an arbitrary heap pointer can address only pages mapped into that process. Reading another process requires either a permission-checked kernel mechanism such asptraceorprocess_vm_readv, deliberately shared memory, or a separate exploit against the kernel or another privileged component. Therefore amallocbug may compromise one process, but accessing another process—or another Qubes VM—requires crossing an additional security boundary.
1 Like
So, is malloc bad or not?
Yep. Malloc is bad. What you malloc is your space. Can’t have other programs access it. But they do so its bad.
In addition to what’s been mentioned, inter-process memory access can also be restricted by AppArmor or SELinux profiles. This is not some shamefully neglected area of system security, it’s ground that has been tread constantly for decades, and has plenty of adequate solutions.
@MasterQube can you at least acknowledge that what you propose is outside the scope of QubesOS and is better handled by another project?
1 Like
It is not outside of scope since it directly affects QubesOS security guarantees. You’re malloc suppliers are bad and you need tell them to do their job properly.
QubesOS says it follows a security by isolation model.
Forget all the technical details about the OS. A user reading Qube’s security model will think the VM’s are isolated from each other and they can type something into an offline vault VM and it will be safe from being sent out over the internet since the VM is isolated and offline. This is not true. Or even just another online VM. Right you send an email in one VM and type in that VM. You as a user don’t expect that what you type in VM1 email gets leaked out through another active VM2 at the same time. But it has happened.
No technical details, just from a users perspective. You believe you can type into a VM securely because its isolated – turns out, not true. You are typing keystrokes leaks to other VM(not isolated) → Internet which breaks QubesOS security guarantees.
Repeating unsubstantiated claims does not make them true.
I’d ask you again to read the docs.
5 Likes
One of my favourite words.
Folks, I think explanation of xen and IOMMU needs to give way to basic process isolation in the Linux kernel.
The Big Blue Bell is calling…
3 Likes
@MasterQube: remember RTFM!!!
2 Likes
No i’m not reading it. QubesOS says its supposed to be secure through isolation. It is not isolated and not secure.
QubesOS is not secure. Do your job properly.
“No i’m not reading it.”
Then we should conclude that you’re not a contributing member of this community and the only rational response to your posts is to ignore them and assume you don’t have a clue what you’re talking about wrt Qubes security.
6 Likes
If you like to continue living in your fool’s paradise, it’s ok. But why should we continue reading your stuff?
3 Likes
off-topic
Are you saying Qubes is not secure because Polish devs created it?
Reminder: this forum is here for public discussion. If you just want others to agree with you, without engaging in a real conversation, I doubt any forum would be an appropriate place for that.
4 Likes