UDP data corruption caused by buggy udp_recvmsg() -> skb_copy_and_csum_datagram_msg()
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Incomplete
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
The Xenial v4.4 kernel (https:/
Details:
For a packet longer than 76 bytes (see line 3951, https:/
In the recvmsg() syscall handler, while Linux is copying the UDP payload to the application’s memory, it calculates the UDP checksum. If the calculated checksum doesn’t match the received checksum, Linux drops the corrupt UDP packet, and then starts to process the next packet (if any), and if the next packet is valid (i.e. the checksum is correct), Linux will copy the valid UDP packet's payload to the application’s receiver buffer.
The bug is: before Linux starts to copy the valid UDP packet, the data structure used to track how many more bytes should be copied to the application memory is not reset to what it was when the application just entered the kernel by the syscall! Consequently, only a small portion or none of the valid packet’s payload is copied to the application’s receive buffer, and later when the application exits from the kernel, actually most of the application’s receive buffer contains the payload of the corrupt packet while recvmsg() returns the size of the UDP payload of the valid packet. Note: this is actually a security vulnerability that can be used to trick the application to think the corrupt packet’s payload is sent from the valid packet’s IP address/port -- so a source IP based security authentication mechanism can be bypassed.
The bug was fixed in this 2017 patch “make skb_copy_
I have the below one-line workaround patch to force the recvmsg() syscall handler to return to the userspace when Linux detects a corrupt UDP packet, so the application will invoke the syscall again to receive the next good UDP packet:
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1367,6 +1367,7 @@ csum_copy_err:
/* starting over for a new packet, but check if we need to yield */
+ return -EAGAIN;
goto try_again;
}
Note: the patch may not work well with blocking sockets, for which typically the application doesn’t expect an error of -EAGAIN. I guess it would be safer to return -EINTR instead.
Hello Dexuan, excellent report, thanks.
Am I reading correctly that this affects strictly UDP? Without the three-way handshake and TCP sequence numbers, UDP sources are relatively easy to spoof in the first place.
If I've read this correctly, I think this is a bug that ought to be fixed, but may not itself allow crossing a security boundary.
Did I misread?
Thanks