CVE-2023-52527

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()<br /> <br /> Including the transhdrlen in length is a problem when the packet is<br /> partially filled (e.g. something like send(MSG_MORE) happened previously)<br /> when appending to an IPv4 or IPv6 packet as we don&amp;#39;t want to repeat the<br /> transport header or account for it twice. This can happen under some<br /> circumstances, such as splicing into an L2TP socket.<br /> <br /> The symptom observed is a warning in __ip6_append_data():<br /> <br /> WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800<br /> <br /> that occurs when MSG_SPLICE_PAGES is used to append more data to an already<br /> partially occupied skbuff. The warning occurs when &amp;#39;copy&amp;#39; is larger than<br /> the amount of data in the message iterator. This is because the requested<br /> length includes the transport header length when it shouldn&amp;#39;t. This can be<br /> triggered by, for example:<br /> <br /> sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP);<br /> bind(sfd, ...); // ::1<br /> connect(sfd, ...); // ::1 port 7<br /> send(sfd, buffer, 4100, MSG_MORE);<br /> sendfile(sfd, dfd, NULL, 1024);<br /> <br /> Fix this by only adding transhdrlen into the length if the write queue is<br /> empty in l2tp_ip6_sendmsg(), analogously to how UDP does things.<br /> <br /> l2tp_ip_sendmsg() looks like it won&amp;#39;t suffer from this problem as it builds<br /> the UDP packet itself.