Skip to content

util-linux

By sorona.xyz Bug bounty on Sorona

Accepting reports open-source
Top reward
$1,500
Top severity paid
Critical
Assets in scope
9
Public CVEs
0
Last change
No changes yet

At a glance

What to know before you start testing.

Pays from $1,500
for critical bugs.
Partial safe harbor
Some legal protection; read the terms.
Publish after a fix
Coordinate the timing with the company.

Rewards

What Sorona lists as the payout for each severity.

Severity Reward
Critical $1,500+
High $700+
Medium $300+
Low $100 $100 / 1 month Claude Max
Safe harbor
Partial Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.

Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original

Scope

9 assets you may test, 4 excluded.

Web 1

  • https://github.com/util-linux/util-linux

Products and areas 8

  • Anything that survives a privilege transition in a setuid or capability-bearing tool: environment variables, arguments, inherited file descriptors and the umask
  • dmesg and wall, which read kernel log data and write to terminals belonging to other users
  • libblkid and its probes: superblock detection, partition-table parsing and topology reads against any device an ordinary user is permitted to attach
  • libuuid, covering generation quality and the assumptions callers make about a generated identifier being unguessable
  • mount(8), umount(8) and libmount: target-path resolution, helper dispatch, fstab handling, the ownership hooks, and everything the privileged path does between checking a path and using it
  • The disk and partition tooling, including fdisk, lsblk and the loop-device setup in losetup
  • The login path: login, su and agetty, together with the password-database and user-lookup helpers behind them, including setpwnam()
  • There is no SECURITY.md and no declared scope. The GitHub private advisory channel is enabled, the maintainers use it, and it takes security defects anywhere in the upstream util-linux tree
Out of scope (4)
  • Configuration mistakes in /etc/fstab or in a distribution's sudoers rules that grant mounting rights the operator chose to grant
  • Crashes in a tool the reporter already had the privilege to run, where no user, mount or ownership boundary is actually crossed
  • Distribution-specific patches and packaging rather than defects in the upstream tree
  • Downstream consumers that link libmount or libblkid, such as systemd and udisks, which are maintained elsewhere

Rules

What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.

While testing

  • Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
  • Report privately with the "Report a vulnerability" button at github.com/util-linux/util-linux/security/advisories/new; the channel is enabled on the repository and the maintainers use it
  • Do not open a public GitHub issue for anything that crosses a privilege boundary; the advisory form is the only private path this project has
  • There is no SECURITY.md and no published embargo window, so state your own preferred timeline in the report rather than assuming one
  • Include the exact reproduction environment: the fstab or mount invocation, the device or image, and the uid the tool ran as.
  • Show the defect in upstream util-linux rather than in a distribution's patched build; distro-only regressions belong with the distributor

Not accepted

  • Distribution-specific patches and packaging rather than defects in the upstream tree
  • Crashes in a tool the reporter already had the privilege to run, where no user, mount or ownership boundary is actually crossed
  • Configuration mistakes in /etc/fstab or in a distribution's sudoers rules that grant mounting rights the operator chose to grant

Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original

Changes

Tracked since 11 Nov 2026. Last checked 1 hour ago.

No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.

Public CVEs

Published vulnerabilities in this vendor's products, from the NVD.

No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.

Original policy

Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 6 Last 12 months Race condition (TOCTOU) 40 % Local privilege escalation 30 % Memory safety 20 % Environment trust 10 % Latest advisories Loading the feed Overview util-linux is the package that makes a Linux system usable: mount and umount , login , su , agetty , lsblk , fdisk and dmesg , sitting on the libmount , libblkid and libuuid libraries that systemd, udisks and the whole storage stack link against. Every Linux deployment ships it, from server to container base image to embedded appliance. Six CVEs landed in the last twelve months, including three separate local privilege escalations in mount(8) published on one day in June 2026. The project has no security policy and pays nothing for any of it, though the private advisory channel is live and worked. sorona.xyz pays you directly on qualified, reproduced findings. In scope There is no SECURITY.md and no declared scope. The GitHub private advisory channel is enabled, the maintainers use it, and it takes security defects anywhere in the upstream util-linux tree mount(8) , umount(8) and libmount : target-path resolution, helper dispatch, fstab handling, the ownership hooks, and everything the privileged path does between checking a path and using it libblkid and its probes: superblock detection, partition-table parsing and topology reads against any device an ordinary user is permitted to attach libuuid , covering generation quality and the assumptions callers make about a generated identifier being unguessable The login path: login , su and agetty , together with the password-database and user-lookup helpers behind them, including setpwnam() The disk and partition tooling, including fdisk , lsblk and the loop-device setup in losetup dmesg and wall , which read kernel log data and write to terminals belonging to other users Anything that survives a privilege transition in a setuid or capability-bearing tool: environment variables, arguments, inherited file descriptors and the umask Out of scope Distribution-specific patches and packaging rather than defects in the upstream tree Downstream consumers that link libmount or libblkid , such as systemd and udisks, which are maintained elsewhere Crashes in a tool the reporter already had the privilege to run, where no user, mount or ownership boundary is actually crossed Configuration mistakes in /etc/fstab or in a distribution's sudoers rules that grant mounting rights the operator chose to grant Most-valued findings A TOCTOU in mount(8) where the path checked is not the path acted on. CVE-2026-53612 and CVE-2026-53614 both landed here, and this class alone is 40 percent of the recent record Ownership or permission application in hook_owner.c that can be redirected onto a file the caller does not own, turning a mount into an arbitrary chown. CVE-2026-53613 is the example Any environment variable, argument or inherited descriptor that changes privileged behaviour after the setuid transition, the LIBMOUNT_FORCE_MOUNT2 class of bug Memory corruption in a libblkid probe reachable by handing the system a crafted filesystem image or removable device, since automounters call this code before any user decision is made. CVE-2026-53615 was an integer overflow on this surface Races in loop-device setup, the shape CVE-2026-27456 took Defects in login , su or the password-database helpers that leak or corrupt credential material, the class CVE-2025-14104 belongs to Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report privately with the "Report a vulnerability" button at github.com/util-linux/util-linux/security/advisories/new; the channel is enabled on the repository and the maintainers use it Do not open a public GitHub issue for anything that crosses a privilege boundary; the advisory form is the only private path this project has There is no SECURITY.md and no published embargo window, so state your own preferred timeline in the report rather than assuming one Include the exact reproduction environment: the fstab or mount invocation, the device or image, and the uid the tool ran as. The recent findings all turn on precise timing and setuid context Show the defect in upstream util-linux rather than in a distribution's patched build; distro-only regressions belong with the distributor Disclosure Coordinated through GitHub private vulnerability reporting, with the outcome published as a GitHub Security Advisory alongside a release. The June 2026 batch shows the maintainers are willing to hold several findings and ship them together, so expect your advisory to be timed against a release rather than against your report date. Because no policy document exists, there is no stated embargo to hold you to and no written commitment on response time. Agree the publication date in the advisory thread. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability