-
Notifications
You must be signed in to change notification settings - Fork 171
socketxtreme: fix NULL m_p_rx_ring crash in rx_input_cb #1154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
socketxtreme: fix NULL m_p_rx_ring crash in rx_input_cb #1154
Conversation
When using unified ring_fd polling, VMA auto-accepts connections. If a client sends data immediately after connect, the packet can arrive before m_p_rx_ring is initialized, causing a NULL pointer dereference in rx_input_cb() / fill_completion(). Fix by deriving the ring from the packet's descriptor owner when m_p_rx_ring is NULL. The descriptor owner is always valid as it points to the ring that received the packet. Fixes: Mellanox#1153 Signed-off-by: Muhammad Nawaz <m.nawaz2003@gmail.com>
|
Can one of the admins verify this patch? |
Greptile OverviewGreptile SummaryFixes NULL pointer dereference crash in SocketXtreme mode when packets arrive for auto-accepted connections before Key Changes:
Technical Correctness:
Confidence Score: 5/5
Important Files ChangedFile Analysis
Sequence DiagramsequenceDiagram
participant Client
participant Listener as Listener Socket
participant Ring as ring_fd (unified)
participant NewSock as New TCP Socket
participant CQ as Completion Queue
Note over Client,CQ: Race Condition Timeline
Client->>Listener: SYN packet
Listener->>Client: SYN-ACK
Client->>Listener: ACK (connection established)
Note over Ring: socketxtreme_poll() on ring_fd
Ring->>Listener: VMA_SOCKETXTREME_NEW_CONNECTION_ACCEPTED
Listener->>NewSock: Create sockinfo_tcp (m_p_rx_ring = NULL)
Note over Client: Client sends data immediately
Client->>CQ: Data packet arrives
CQ->>Ring: Packet queued
Note over Ring: socketxtreme_poll() continues processing
Ring->>NewSock: rx_input_cb(desc) called
alt Without Fix (CRASH)
NewSock->>NewSock: m_p_rx_ring->get_comp()
Note over NewSock: SIGSEGV! m_p_rx_ring is NULL
end
alt With Fix (SAFE)
NewSock->>NewSock: if (!m_p_rx_ring)
NewSock->>NewSock: m_p_rx_ring = desc->p_desc_owner
NewSock->>NewSock: m_p_rx_ring->get_comp() ✓
Note over NewSock: No crash, ring derived from descriptor
end
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 files reviewed, no comments
|
@galnoam, please assign reviewer |
When using unified ring_fd polling, VMA auto-accepts connections. If a client sends data immediately after connect, the packet can arrive before
m_p_rx_ringis initialized, causing a NULL pointer dereference inrx_input_cb()/fill_completion().Fix by deriving the ring from the packet's descriptor owner when
m_p_rx_ringis NULL. The descriptor owner is always valid as it points to the ring that received the packet.Fixes: #1153
Description
What
Fix SocketXtreme NULL pointer dereference in
rx_input_cb()(TCP) andfill_completion()(UDP) when a packet arrives for an auto-accepted socket whosem_p_rx_ringhas not been initialized yet.Why
With unified
ring_fdpolling, VMA auto-accepts connections. If the client sends data immediately after connect, CQ processing can invokerx_input_cb()beforem_p_rx_ringis set:How
Derive the ring from the packet's descriptor owner on the rare uninitialized path:
The descriptor owner always points to the ring that received the packet, providing a valid fallback. The
unlikely()hint ensures no hot-path performance impact.Change Type
Checklist
Files Changed
src/vma/sock/sockinfo_tcp.cppm_p_rx_ringinrx_input_cb()src/vma/sock/sockinfo_udp.cppm_p_rx_ringinfill_completion()Testing
Environment:
Results:
rx_input_cb()within secondsReproduction
Standalone reproduction code available with issue reported as #1153
Key conditions:
ring_fdfrom listener (get_socket_rings_fds)