wfc-pkt-router can wrongly bind to external network interface instead of VPN tunnel There is a daemon called \"wfc-pkt-router\" (the \"IMS packet router daemon\" according to https://github.com/ItsLynix/samsung_a53x_dump/blob/36de1bc4f9a9b3646809805b9feaf2f4396177e5/vendor/etc/init/init.s5e8825.rc) on some Samsung-based phones, including Pixel 7 and (according to that github link) Samsung a53xnaxx (?). When WiFi Calling is active, this daemon is responsible for forwarding IP packets between the baseband (/dev/umts_wfc1 on Pixel 7) and an IPSec tunnel provided by Android. wfc-pkt-router creates a raw socket bound to a specific interface (using SO_BINDTODEVICE) and forwards raw IP packets between the interface-bound socket and the baseband (/dev/umts_wfc1). Some other mechanism outside wfc-pkt-router (I have no idea how that works) apparently causes Android to set up an IPSec tunnel with a local IP address that is also known to the baseband. When the baseband starts using an IPSec tunnel via wfc-pkt-router, it has to tell wfc-pkt-router which interface to bind to. The baseband does this by telling wfc-pkt-router the local IP address of the IPSec tunnel; wfc-pkt-router then scans through the list of network interfaces (using getifaddrs()) and searches for a matching interface. If multiple interfaces match, it picks the *newest* interface with the right IP address. The main problem with this is that multiple interfaces can have the same local IP address. IPSec interfaces are created dynamically, so they are typically created later than WiFi interfaces or such, which means an address collision with a WiFi interface is not a problem *as long as the IPSec interface exists*; but the interfaces associated with USB ethernet adapters or VPN apps can be dynamically created after the IPSec interface creation. I have experimentally tested on a Pixel 7 that, if a USB ethernet adapter is inserted after the IPSec interface was created, and the DHCP server assigns the same IP address that is also used for the IPSec tunnel, traffic intended for the IPSec tunnel flows bidirectionally between the baseband and the ethernet adapter - I saw an outgoing SIP connection attempt that I could intercept and reply to. (This requires that the IP address used inside IPSec is IPv4 - I have seen one provider that uses IPv4 inside the IPSec tunnel and another one that uses IPv6.) I recommend that you give wfc-pkt-router the right interface name somehow instead of letting it search for the right interface based on IP address. --- Additional Comments --- Because of the bug, the baseband's SIP connection does *NOT* go through the IPSec tunnel. So the protections provided by IPSec become irrelevant. The normal flow of data for wifi calling is like this: 1. baseband generates a TCP SYN packet 2. baseband puts the TCP SYN packet in an unencrypted IP packet 3. baseband sends the unencrypted IP packet to wfc-pkt-router (on the AP) 4. wfc-pkt-router sends the unencrypted IP packet to "ipsec*" network interface 5. Linux kernel IPSec/xfrm layer encrypts the IP packet 6. Linux kernel sends encrypted IP packet over wifi or whatever But when the bug is hit, the data flow is instead like this: 1. baseband generates a TCP SYN packet 2. baseband puts the TCP SYN packet in an unencrypted IP packet 3. baseband sends the unencrypted IP packet to wfc-pkt-router (on the AP) 4. wfc-pkt-router sends the unencrypted IP packet to eth0 network interface So the unencrypted IP packet from the baseband is directly sent out of the phone. The other direction works the same way. Samsung Device Solution BU's PSIRT (dsprodsec) let me know that they plan to list this in their bulletin as: CVE-2023-29092 Improper handling of parameters while binding network interface Exynos Mobile Processor and Modem Exynos Modem 5123, Exynos Modem 5300, Exynos 980, Exynos 1080 Denial of Service Attacker insert malicious configured USB ethernet adapter Binding wrong resource can occur due to improper handling of parameters while binding network interface 3.1 Low CVSS:3.1/AV:P/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:L https://source.android.com/docs/security/bulletin/pixel/2023-04-01 says CVE-2023-29092 was fixed at the 2023-04-05 patch level. This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2023-05-08. Related CVE Numbers: CVE-2023-29092wasfixedatthe2023-04-05patchlevel,CVE-2023-29092. Found by: jannh@google.com