Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta Para iniciantes
  • Algo errado?
#263 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
62/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
c, go
Domínio
operating-systems

Direção de pesquisa

Comece em mount/mounter_openbsd.go: leia createUfsArgs (por volta da linha 42) e a função mount que chama C.mount (por volta da linha 66), depois compare com o padrão defer C.free em mounter_freebsd.go (linhas 46-49). Está pronto quando cada alocação de C.CString é liberada e o preâmbulo do cgo inclui stdlib.h. O build do OpenBSD não pode ser executado localmente, então verifique se o arquivo ainda compila para o target openbsd com cgo.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Go
Estrelas
102
Forks
62
Merge médio
3min
PRs com merge (30d)
1

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de moby/sys

Todas as issues de moby/sys

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.