Part of manpage appeared in /dev/random output

[sadegr]

Windows Version

10.0.19045.5965

WSL Version

2.5.7.0

Are you using WSL 1 or WSL 2?

• [x] WSL 2
• [ ] WSL 1

Kernel Version

6.6.87.1

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

I ran cat /dev/random and then hit ctrl+C after second or 2.

Among the mostly random noise, I noticed this snippet in the output toward the end:

<random noise>Resable interpretation of backslash escapes<random noise>

(unfortunately I seem to have lost the exact <random noise> as my terminal's scrollback buffer only goes back so far)

Interestingly the following lines appear in the output of man echo - which I should note I don't believe I ever ran prior to seeing the output of /dev/random (but see the note at the bottom):

       -e     enable interpretation of backslash escapes

       -E     disable interpretation of backslash escapes (default)

This surprised me. My understanding was that /dev/random on Linux is supposed to produce cryptographically secure pseudorandom data.

Assuming this is not an extremely unlikely coincidence, is it known/expected behavior for /dev/random to occasionally output snippets of files/command output/etc. on WSL2?

Note

I also want to note that it's possible that I did run man echo at one point before the cat /dev/random that produced the output in question, although my shell's (zsh) history command seems to suggest I only ran man echo after the cat /dev/random that produced the aforementioned string. I'm just not 100% sure of the order of these 2 events in relation to one another as I also ran several other commands afterward, so wanted to call it out in case I misremembered. Regardless, I still wouldn't expect cat /dev/random to output parts of the output of a command I ran previously, if that is what happened here.

Expected Behavior

cat /dev/random does not print parts of files in the file system

Actual Behavior

Output contained a reasonably long substring of a manpage

Diagnostic Logs

No response

[github-actions[bot]]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'. Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

[sadegr]

/question

[github-actions[bot]]

Diagnostic information

Found '/question', adding tag 'question'

[sadegr]

WslLogs-2025-06-16_22-57-21.zip

[github-actions[bot]]

The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running.

Diagnostic information

Detected appx version: 2.5.7.0
Found no WSL traces in the logs

[sirredbeard]

Interesting.

/dev/random should block (unlike /dev/urandom) until the entropy pool is sufficiently seeded and mixed. Instead, you seem to be getting unitialized stack or page cache memory that still holds fragments from likely running man prior to cat /dev/random.

In WSL2 kernel 6.6.87.1, the following configs are set:

CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TPM=y

But there is no /sys/class/hw_random/.

/sys/module/random/ exists, random is coming from...somewhere?

But if random exists, but hw_random is not being loaded, random must be seeded just from memory? That may not supply sufficient entropy.

This random config in WSL2 6.6.y is a departure from the WSL2 6.1.y configs, which did not rely on HW_RANDOM:

# CONFIG_HW_RANDOM is not set
CONFIG_RANDOM_TRUST_CPU=y

There are no substantive changes in the CONFIG_CRYPTO_* sections between 6.6.y and 6.1.y, nor are their substantive changes in CONFIG_HYPERV* between same.

I do know that the Hyper-V kernel modules can seed additional entropy from the host, both via randomness supplied at boot through UEFI (in 6.9+) and I suspect through VMBus.

Edit: Also, it does appear that WSL2 creates /dev/random here and seeds entropy at boot here.

I wonder if the CONFIG_HW_RANDOM change is causing reduced entropy in 6.6.87.1+.

These changes in the 6.6.y kernel were introduced in commit 4d72cb5bb5d14e520500e84316a5b7e0f9e572cf which has raised other issues, see https://github.com/microsoft/WSL/issues/12987, https://github.com/microsoft/WSL/issues/12983, and https://github.com/microsoft/WSL/issues/13031. I am curious is this a regression caused by that commit.

[sirredbeard]

Curiously, I can't seem to drain /dev/random with the following on 6.6.y or earlier kernels:

#/bin/bash
while [ "$(cat /proc/sys/kernel/random/entropy_avail)" -gt 0 ]; do
  dd if=/dev/random of=/dev/null bs=1 count=1 2>/dev/null
done
echo "Entropy pool drained; new requests will block until reseeded."

Even though:

cat /proc/sys/kernel/random/entropy_avail /proc/sys/kernel/random/poolsize
256
256

Maybe /proc/sys/kernel/random/entropy_avail is hardcoded somehow to 256, so don't rely on that:

#!/bin/bash
while dd if=/dev/random of=/dev/null bs=1 count=1 2>/dev/null; do
  :
done
echo "Entropy pool drained; new requests will block until reseeded."

Never finishes.

Odd.

[0xbadfca11]

New requests never block now. https://lwn.net/Articles/808575/ entropy_avail is immutable. https://github.com/microsoft/WSL2-Linux-Kernel/commit/e85c0fc1d94c52483a603651748d4c76d6aa1c6b#diff-a842fe5b90bcdeefd9e51e08d7d2b1e76cbd46be6308fddf9f8922450c135f8fR1677

[sirredbeard]

Thank you @0xbadfca11 I guess I am showing my age working with the kernel.

[sirredbeard]

That goes back to my theory that the change to:

CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TPM=y

Simply isn't providing enough real entropy for true random.

Pinging @OneBlue for thoughts.

[OneBlue]

Answering both questions here:

among the mostly random noise, I noticed this snippet in the output toward the end: [...] I also want to note that it's possible that I did run man echo at one point before the cat /dev/random that produced the output in question

/dev/random random bytes, which has the potential of generating terminal escape sequence, which can essentially cause any and all terminal behavior to trigger, which explain what you saw (the output of previous command being displayed again).

Pinging @OneBlue for thoughts.

Entropy for /dev/random comes from the host , and is injected in the VM

[sadegr]

Edit: inspected output in a text editor and the repetition I'm seeing within the /dev/random output itself (e.g. 2 subsequent lines starting with same prefix) which I had initially reported in this comment is indeed due to terminal escape sequences. I haven't been able to reproduce the original issue after the first time I saw it but I'll assume it's the same thing. Thanks for the pointer.