Bug 275774
| Summary: | IPv4 Mapper address problem | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Emmanuel Vadot <manu> | ||||||||
| Component: | kern | Assignee: | freebsd-net (Nobody) <net> | ||||||||
| Status: | Closed FIXED | ||||||||||
| Severity: | Affects Only Me | CC: | emaste, glebius, tuexen | ||||||||
| Priority: | --- | Flags: | linimon:
mfc-stable14?
linimon: mfc-stable13? |
||||||||
| Version: | 15.0-CURRENT | ||||||||||
| Hardware: | Any | ||||||||||
| OS: | Any | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 247055 [details]
udptest_recv
Created attachment 247056 [details]
Fix IPv4 mapped address
Can you please create phabricator review instead? Broken by abca3ae7734f6 I guess. The patch looks 100% correct to me, but let's wait for Michael to review. It'll also be cool to rework test program to atf(3) and land it in tests/netinet. (In reply to Gleb Smirnoff from comment #5) Patch looks good to me. I think you don't need to initialize `use_cached_route` to `false` in the patch. (In reply to Gleb Smirnoff from comment #4) Could be but reverting this commit locally to test this makes the panic re-appears so I'm not sure if this was working before, could also be later modification as I didn't test the previous hash directly. Thanks both for your review, will commit later today (after writing a better commit message :P) (In reply to Emmanuel Vadot from comment #8) Please include in your commit message: Reported-by: syzbot+618d4f014f60c0bd06b4@syzkaller.appspotmail.com since this patch also fixes https://syzkaller.appspot.com/bug?extid=618d4f014f60c0bd06b4 A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=7df9da47e8f04267330e1baa751f07c0c4aaf2ac commit 7df9da47e8f04267330e1baa751f07c0c4aaf2ac Author: Richard Kümmel <R.Kuemmel@beckhoff.com> AuthorDate: 2023-12-15 11:49:45 +0000 Commit: Emmanuel Vadot <manu@FreeBSD.org> CommitDate: 2024-01-02 06:49:12 +0000 Fix udp IPv4-mapped address Do not use the cached route if the destination isn't the same. This fix a problem where an UDP packet will be sent via the wrong route and interface if a previous one was sent via them. PR: 275774 Reviewed by: glebius, tuexen Sponsored by: Beckhoff Automation GmbH & Co. KG sys/netinet/udp_usrreq.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3159e314f194bd8db98dd4516f46350b2fbe44f0 commit 3159e314f194bd8db98dd4516f46350b2fbe44f0 Author: Richard Kümmel <R.Kuemmel@beckhoff.com> AuthorDate: 2023-12-15 11:49:45 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2024-01-10 16:37:44 +0000 Fix udp IPv4-mapped address Do not use the cached route if the destination isn't the same. This fix a problem where an UDP packet will be sent via the wrong route and interface if a previous one was sent via them. PR: 275774 Reviewed by: glebius, tuexen Sponsored by: Beckhoff Automation GmbH & Co. KG (cherry picked from commit 7df9da47e8f04267330e1baa751f07c0c4aaf2ac) sys/netinet/udp_usrreq.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) Can we close this? (In reply to Michael Tuexen from comment #12) Yes :) |
Created attachment 247054 [details] udptest Hi, We have a problem at work with IPv4-Mapped address. Attached is two test program, udptest and udptest_recv. The first one send a udp datagram to 127.0.0.1 and if a response is received it will send another one to the given ip address given in the first args. So we have machine A and machine B. - Start udptest_recv on machine A - Start udptest_recv on machine B - tcpdump -i lo0 on machine A - Start udptest XXX.XXX.XXX.XXX (ipv4 of machine B) on machine A What is expected : - machine A send 'abcd' to 127.0.0.1 - machine A receive 'abcd' - machine A sends back 'abcd' to machine A - machine A send 'efgh' to machine B - machine B receive 'efgh' from machine A What is happening : - machine A send 'abcd' to 127.0.0.1 - machine A receive 'abcd' - machine A sends back 'abcd' to machine A - machine A send 'efgh' to machine A - machine A receive 'efgh' from machine A - machine B receives nothing tcpdump -i lo0 on machine A gives us : tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on lo0, link-type NULL (BSD loopback), snapshot length 262144 bytes 13:17:46.418063 IP 127.0.0.1.34254 > 127.0.0.1.1234: UDP, length 4 13:17:46.418233 IP 127.0.0.1.1234 > 127.0.0.1.34254: UDP, length 4 13:17:46.418341 IP 192.168.1.51.34254 > 192.168.1.50.1234: UDP, length 4 192.168.1.51 is the IPv4 of machine A and 192.168.1.50 the one of machine B So the second udp packet is send via lo0 Attached is also a patch that fixes it but we're not sure if that's the best way or not as we don't have much knowledge of our IP stack. On 13.2 the correct behavior is happening. On 15-CURRENT (3494f7c019fc6558a99f63 from December 8 2023) it doesn't work. Not tested on 14.0 (yet).