[Bug 297380] netmap_ring_reinit() can run off the end of the slot[] array

[email protected]
Newsgroups gmane.os.freebsd.bugs
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297380

            Bug ID: 297380
           Summary: netmap_ring_reinit() can run off the end of the slot[]
                    array
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: [email protected]
          Reporter: [email protected]
 Attachment #273559 text/plain
         mime type:

Created attachment 273559
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=273559&action=edit
cause netmap_ring_reinit() to index off the end of slot[]

The attached program asks netmap for nr_mode=7 (NR_REG_NULL),
nr_rx_rings=1, and nr_rx_slots=0. The NR_REG_NULL causes the netmap to
be initialized with netmap_get_null_na(), which accepts rings=1 and
slots=0 as is. Then the program calls poll(), which results in
netmap_ring_reinit() being called, which says

        u_int i, lim = kring->nkr_num_slots - 1;
        ...;
        for (i = 0; i <= lim; i++) {

But num_slots is zero, so lim is 0xffffffff, so the for loop indexes
off the end of ring->slot[].

# cc netmap7b.c 
# uname -a
FreeBSD xxx 16.0-CURRENT FreeBSD 16.0-CURRENT #37 main-n275529-da69298e9825:
Fri Jul 17 07:08:15 AST 2026    
root@xxx:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
# ./a.out
...
panic: vm_fault_lookup: fault on nofault entry, addr: 0xfffffe0160765000
panic() at panic+0x43/frame 0xfffffe00d75456e0
vm_fault() at vm_fault+0x1db6/frame 0xfffffe00d7545870
vm_fault_trap() at vm_fault_trap+0x65/frame 0xfffffe00d75458b0
trap_pfault() at trap_pfault+0x295/frame 0xfffffe00d7545920
calltrap() at calltrap+0x8/frame 0xfffffe00d7545920
--- trap 0xc, rip = 0xffffffff807ef3ce, rsp = 0xfffffe00d75459f0, rbp =
0xfffffe00d7545a60 ---
netmap_ring_reinit() at netmap_ring_reinit+0x18e/frame 0xfffffe00d7545a60
netmap_poll() at netmap_poll+0x571/frame 0xfffffe00d7545b40
freebsd_netmap_poll() at freebsd_netmap_poll+0x3f/frame 0xfffffe00d7545b70
devfs_poll_f() at devfs_poll_f+0x8a/frame 0xfffffe00d7545bc0
kern_poll_kfds() at kern_poll_kfds+0x3f6/frame 0xfffffe00d7545c60
kern_poll() at kern_poll+0x111/frame 0xfffffe00d7545dc0
sys_poll() at sys_poll+0x5b/frame 0xfffffe00d7545df0
amd64_syscall() at amd64_syscall+0x17c/frame 0xfffffe00d7545f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00d7545f30
--- syscall (209, FreeBSD ELF64, poll), rip = 0x82366748a, rsp = 0x821023868,
rbp = 0x821023910 ---

-- 
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.