View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006662 | unreal | ircd | public | 2026-11-12 21:26 | 2026-11-12 21:26 |
| Reporter | mattf | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 6.2.7.1 | ||||
| Summary | 0006662: WHO and TOPIC leak +p (private) channel info to non-members | ||||
| Description | This was found through an agentic-driven scan of the source and is part of a batch of non-critical issues I found worth reporting. On a +p channel (private, but not +s secret), the WHO and TOPIC paths treat the channel as if it were public, while the rest of the code hides it, so the surfaces disagree with each other. - WHO: in src/modules/whox.c the non-member branch gates on SecretChannel() only (else if (!SecretChannel(channel))). The HiddenChannel() (+p) half that the old WHO path had is missing, so a non-member who runs WHO on the channel gets the member rows. NAMES on the same channel returns only the 366 end marker. - TOPIC: in src/modules/topic.c the read path gates on SecretChannel() only (if (parc > 2 || SecretChannel(channel))), so a non-member can read the topic (332) and the setter (333) of a +p channel. This is best seen as a consistency bug: WHO and TOPIC are the odd ones out versus NAMES, WHOIS and LIST, which all hide +p members from non-members. Similar issues: - https://bugs.unrealircd.org/view.php?id=4575 | ||||
| Steps To Reproduce | 1. A client joins #test, sets it +p (private, not +s), and is not +i. 2. A second client that is not a member runs WHO #test and gets the member rows. 3. The same client runs NAMES #test and gets only the 366 end marker, so the two disagree. 4. The same client runs TOPIC #test and gets the topic (332) and setter (333); on a +s channel this would be 442. | ||||
| Additional Information | Suggested fix: also check HiddenChannel() in both places, i.e. gate the WHO non-member branch on "!SecretChannel && !HiddenChannel", and add HiddenChannel() to the TOPIC read gate. One related foot-gun I noticed: setting +s and +p together, or adding +p to a +s channel, silently keeps only +p (the leaky state) with no warning. Let me know if this is desired and I could PR it myself. | ||||
| 3rd party modules | |||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-11-12 21:26 | mattf | New Issue |
