Possible memory leak in mount on OpenBSD: C strings passed to mount(2) are never freed
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 62/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- operating-systems
Hướng nghiên cứu
Bắt đầu từ mount/mounter_openbsd.go: đọc createUfsArgs (khoảng dòng 42) và hàm mount gọi C.mount (khoảng dòng 66), sau đó so sánh với mẫu defer C.free trong mounter_freebsd.go (dòng 46-49). Công việc hoàn thành khi mọi cấp phát C.CString đều được giải phóng và phần preamble cgo có bao gồm stdlib.h. Bản build OpenBSD không thể chạy cục bộ, vì vậy hãy kiểm tra xem tệp vẫn biên dịch được cho target openbsd với cgo hay không.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Go
- Star
- 102
- Fork
- 62
- Merge trung bình
- 3 phút
- Pull request đã merge (30 ngày)
- 1
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của moby/sys
-
devices: ignore .incus-mounts in GetDevicesCó thể đã có người làm @SashaMIT đã nhận 5 ngày trước. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
-
[userns-remap] Bug: ToHost incorrectly maps non-root container UID to root when it collides with RootPairCó thể đã có người làm @okhowang đã nhận 71 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 74/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
Issue tương tự
-
os: RawConn methods of a closed File return internal/poll.ErrFileClosing instead of ErrClosedĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: Bedrock invoke-with-response-stream reports `stop_reason: "end_turn"` for tool-use turnsĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
oalders/clodhopper#162 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
component/server severity/minor type/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
diagnose globalnet reports a failure for every exported headless ServiceCó thể đã có người làm @kurtyoon đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
submariner-io/subctl#1948 ·
Maintainer thường phản hồi trong vòng 1 ngày