In the Linux kernel, the following vulnerability has been resolved: smb: client: make use of smbdirect_socket.recv_io.credits.available The logic off managing recv credits by counting posted recv_io and granted credits is racy. That's because the peer might already consumed a credit, but between receiving the incoming recv at the hardware and processing the completion in the 'recv_done' functions we likely have a window where we grant credits, which don't really exist. So we better have a de
In the Linux kernel, the following vulnerability has been resolved:
smb: client: make use of smbdirect_socket.recv_io.credits.available
The logic off managing recv credits by counting posted recv_io and granted credits is racy.
That's because the peer might already consumed a credit, but between receiving the incoming recv at the hardware and processing the completion in the 'recv_done' functions we likely have a window where we grant credits, which don't really exist.
So we better have a decicated counter for the available credits, which will be incremented when we posted new recv buffers and drained when we grant the credits to the peer.
왜 이 VPI인가 (설명가능 · 실험적)
VPI 산정 기준
| 영향도 | 47.00 |
| 악용 신호(추가 악용신호 없음) | ×1.00 |
| VPI | 47.00 |
VPI 공식 vpi-v1 기준