In a QueryDisplayInfo2 RPC call to the samr RPC service, the client
specifies start_idx and max_entries values. These are passed to
pdb_search_entries(), which says

        uint32_t end_idx = start_idx+max_entries-1;

        end_entry = pdb_search_getentry(search, end_idx);
        *result = pdb_search_getentry(search, start_idx);

        if (end_entry != NULL)
                return max_entries;

I think the code intends to return the number of entries fetched.
However, if the client's start_idx is huge, and adding max_entries-1
wraps to zero, then the first call to pdb_search_getentry() can
succeed even though the second unexpectedly fails to retrieve
anything. The result is that pdb_search_entries() can return a value
greater than zero, signifying success, even though it has set *result
to NULL.

Here's a backtrace caused by a client that sends start_idx=4294966614
and max_entries=683. entries is NULL even though num_entries is
positive.

Program received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
0x00003f546a4e83e2 in init_samr_dispinfo_1 (ctx=0x3f5cdb3568f0, 
    r=0x3f5cdb3576a0, num_entries=683, start_idx=4294966614, entries=0x0)
    at ../../source3/rpc_server/samr/srv_samr_nt.c:1285
1285                                    entries[i].account_name);
(gdb) where
#0  0x00003f546a4e83e2 in init_samr_dispinfo_1 (ctx=0x3f5cdb3568f0, 
    r=0x3f5cdb3576a0, num_entries=683, start_idx=4294966614, entries=0x0)
    at ../../source3/rpc_server/samr/srv_samr_nt.c:1285
#1  0x00003f546a4e8064 in _samr_QueryDisplayInfo (p=0x3f5cdb333d08, 
    r=0x3f5c8aa45850) at ../../source3/rpc_server/samr/srv_samr_nt.c:1623
#2  0x00003f546a4e8bf4 in _samr_QueryDisplayInfo2 (p=0x3f5cdb333d08, 
    r=0x3f5cdb356dd0) at ../../source3/rpc_server/samr/srv_samr_nt.c:1691