Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Possible memory leak in mount on OpenBSD: C strings passed to mount(2) are never freed

Ouverte Adaptée aux débutants
#263 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
62/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
c, go

Piste de recherche

Commence par mount/mounter_openbsd.go : lis createUfsArgs (vers la ligne 42) et la fonction mount qui appelle C.mount (vers la ligne 66), puis compare-les avec le motif defer C.free de mounter_freebsd.go (lignes 46-49). C'est terminé lorsque chaque allocation C.CString est libérée et que le préambule cgo inclut stdlib.h. Le build OpenBSD ne peut pas être exécuté localement, donc vérifie que le fichier compile toujours pour la cible openbsd avec cgo.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

On OpenBSD with cgo, every mount.Mount(..., "ffs", ...) call allocates three C strings that are never freed: fspec: C.CString(device) in createUfsArgs (mount/mounter_openbsd.go:42), and C.CString(mType) / C.CString(target) passed inline to C.mount (:66). mount(2) copies its arguments, so they can be freed right after the call; mounter_freebsd.go:46-49 already does this with defer C.free.

Details

Commit: 0922b4fee15d (//go:build openbsd && cgo). The file has no C.free and does not include <stdlib.h>. The leak is on both the success and the error path, len(device)+len(target)+6 bytes per call.

I don't have an OpenBSD machine. I copied createExportInfo, createUfsArgs and mount verbatim into a small program with a stub mount() that copies its string arguments and keeps nothing, and measured on macOS:

100,000 calls, current code: +4,800,448 bytes (48 bytes per call)
100,000 calls, with the change below: +0 bytes

With device="/dev/sd0a" and target="/mnt/data" the three strings are 24 bytes; the allocator reports 48 bytes per call because each small allocation is rounded up to 16 bytes.

Possible change in mount(), replacing the createUfsArgs call (and adding #include <stdlib.h> to the existing cgo preamble):

cdev := C.CString(device)
defer C.free(unsafe.Pointer(cdev))
args := C.struct_ufs_args{fspec: cdev, export_info: createExportInfo(readOnly)}
ctype := C.CString(mType)
defer C.free(unsafe.Pointer(ctype))
ctarget := C.CString(target)
defer C.free(unsafe.Pointer(ctarget))
if errno := C.mount(ctype, ctarget, C.int(flag), unsafe.Pointer(&args)); errno != 0 {

Separately (not part of this issue): :66 treats the return value of mount as an errno. mount(2) returns -1 and sets errno, so the error currently reads "errno -1" instead of the real error. mounter_freebsd.go does the same with nmount. Happy to open a separate issue for that if useful.

AI disclosure: I found and analysed this with AI assistance (Claude); the reproduction above was run, and I reviewed and edited this report before posting.

If you could credit me as a reporter for my contributions to security advisory I will be thankful.

Langage dominant
Go
Étoiles
102
Forks
62
Merge moyen
3 min
PR mergées (30 j)
1

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de moby/sys

Toutes les issues de moby/sys

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.