Suppose I'm receiving IPv4 UDP packets whose payload is less than 18 octets, so when they are transmitted over Ethernet they have some trailing padding. The equipment generating said packets includes the length of the padding in the IP header's total length field. So, for example, a packet with a 7-octet-long payload will not have an IP total length of 35, but rather 46.
Where did you get that idea?
Ethernet is a layer-2 protocol, and it doesn't know about the layer-3 protocol. Ethernet can carry any number of layer-3 protocols (IPv4, IPX, IPv6, AppleTalk, etc.), and it knows nothing about the layer-3 protocols or headers for the layer-3 protocols, so it has no way to change a field in a layer-3 header.
Conversely, the layer-3 protocol has no idea which layer-2 protocol (ethernet, Wi-Fi, token ring, frame relay, ATM, PPP, etc.) carries its packets.
The ethernet padding is for ethernet frames at layer-2, not the layer-3 packets.
Edit:
You completely changed the meaning of the question, which is very bad form, especially when you already got an answer to the original question. You should start a new question for a different question, not change the original question.
The device in the middle that changes the IPv4 header total length field must change the IPv4 header checksum, and the UDP checksum (if it used, but it is optional for IPv4, and it is often not used) is not computed using the IPv4 total length field or checksum, so it would not change.
If the IPv4 total length field is changed, then IPv4 will send its original payload (the UDP datagram) and the padding to UDP.
The UDP header has its own length field. If the device does not modify this field, then the UDP will be correct and UDP will send the correct number of octets (not including the padding) to the application, but if the device changes the UDP length field, then the UDP checksum will be recomputed and UDP will send the original UDP payload, plus the padding to the application, possibly causing a problem for the application.
Unless you have implemented transport layer encryption or application level encryption or data signing, there is no way to tell if anyone has manipulated your UDP datagram - whether in content or in size. Manipulation has to include recalculating the checksum, of course.
The checksum's only purpose is to provide transport integrity against accidental changes, i.e. the receiving IP stack can see whether the datagram has been damaged in transport and will then discard it - silently, as it's UDP.
If a deeper layer is using a checksum - as in Ethernet's link layer - the damaged packet/frame has already been discarded on the way, long before reaching the destination.
Best Answer
The answer you are looking for can be found here
For completion reasons, I paste it here:
"First, the checksum calculation is defined in RFC 768 but hints as to how to calculate it efficiently are in RFC 1071. Both are worth reading and contain a much more in-depth description that I'm going to write here.
The basic idea is that the UDP checksum is a the complement of a 16-bit one's complement sum calculated over an IP "pseudo-header" and the actual UDP data. The IP pseudo-header is the source address, destination address, protocol (padded with a zero byte) and UDP length. So to take the example of this short packet, the source IP address is 152.1.51.27, and the destination IP address is 152.14.94.75. Divided into 16-bit quantities, these are 0x9801, 0x331b and 0x980e, 0x5e4b. If you add those together using two's complement (e.g. with Windows calculator), you get 0x1c175. Note that this overflows a 16-bit quantity, but we'll take care of that later. Next is to add in the protocol and UDP length. For this packet, the protocol is UDP so the protocol type byte is 17or 0x11. We pad that with zero to get 0x0011 and then add the UDP length which is 0x000a (10 bytes). So 0x1c175 + 0x0011 + 0x0! 00a = 0x1c190.
Now we add the entire UDP datagram, treating it all as 16-bit quantities and skipping the checksum (until we finish calculating it!). For this datagram, that's 0xa08f, 0x2694, 0x000a, 0x6262, so if we add all that to our running sum, we get 0x1c190 + 0xa08f + 0x2694 + 0x000a + 0x6262 = 0x2eb1f.
Now to convert to a ones complement 16-bit sum we just treat our current sum (0x2eb1f) as a 32-bit quantity and add the high half to the low half. 0x0002 + 0xeb1f = 0xeb21. (If that still had an overflow, we'd add the high and low halves again until there was no longer an overflow.) Now we complement that quantity (i.e. flip all the bits, or do a NOT operation) and we get a value of 0x14de which is exactly what the reported checksum shows in the packet."