cbcvebase.
CVE-2023-52527
published 2024-03-02

CVE-2023-52527: In the Linux kernel, the following vulnerability has been resolved: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data() Including the transhdrlen…

PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.23%
13.4th percentile
In the Linux kernel, the following vulnerability has been resolved: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data() Including the transhdrlen in length is a problem when the packet is partially filled (e.g. something like send(MSG_MORE) happened previously) when appending to an IPv4 or IPv6 packet as we don't want to repeat the transport header or account for it twice. This can happen under some circumstances, such as splicing into an L2TP socket. The symptom observed is a warning in __ip6_append_data(): 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 that occurs when MSG_SPLICE_PAGES is used to append more data to an already partially occupied skbuff. The warning occurs when 'copy' is larger than the amount of data in the message iterator. This is because the requested length includes the transport header length when it shouldn't. This can be triggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, ...); // ::1 connect(sfd, ...); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024); Fix this by only adding transhdrlen into the length if the write queue is empty in l2tp_ip6_sendmsg(), analogously to how UDP does things. l2tp_ip_sendmsg() looks like it won't suffer from this problem as it builds the UDP packet itself.

Affected

24 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.1.64-1 (bookworm)linux 6.1.64-1 (bookworm)
linuxlinux
linuxlinux>= a32e0eec7042b21ccb52896cf715e3e2641fed93 < 7626b9fed53092aa2147978070e610ecb61af8447626b9fed53092aa2147978070e610ecb61af844
linuxlinux>= a32e0eec7042b21ccb52896cf715e3e2641fed93 < 559d697c5d072593d22b3e0bd8b8081108aeaf59559d697c5d072593d22b3e0bd8b8081108aeaf59
linuxlinux>= a32e0eec7042b21ccb52896cf715e3e2641fed93 < 1fc793d68d50dee4782ef2e808913d5dd880bcc61fc793d68d50dee4782ef2e808913d5dd880bcc6
linuxlinux>= a32e0eec7042b21ccb52896cf715e3e2641fed93 < 96b2e1090397217839fcd6c9b6d8f5d439e705ed96b2e1090397217839fcd6c9b6d8f5d439e705ed
linuxlinux>= a32e0eec7042b21ccb52896cf715e3e2641fed93 < cd1189956393bf850b2e275e37411855d3bd86bbcd1189956393bf850b2e275e37411855d3bd86bb
linuxlinux>= a32e0eec7042b21ccb52896cf715e3e2641fed93 < f6a7182179c0ed788e3755ee2ed18c888ddcc33ff6a7182179c0ed788e3755ee2ed18c888ddcc33f
linuxlinux>= a32e0eec7042b21ccb52896cf715e3e2641fed93 < fe80658c08e3001c80c5533cd41abfbb0e0e28fdfe80658c08e3001c80c5533cd41abfbb0e0e28fd
linuxlinux>= a32e0eec7042b21ccb52896cf715e3e2641fed93 < 9d4c75800f61e5d75c1659ba201b6c0c7ead30709d4c75800f61e5d75c1659ba201b6c0c7ead3070
linuxlinux_kernel
linuxlinux_kernel>= 0 < 5.10.205-15.10.205-1
linuxlinux_kernel>= 0 < 6.1.64-16.1.64-1
linuxlinux_kernel>= 0 < 6.5.8-16.5.8-1
linuxlinux_kernel>= 0 < 6.5.8-16.5.8-1
linuxlinux_kernel>= 0 < 4.4.0-259.2934.4.0-259.293
linuxlinux_kernel>= 0 < 4.15.0-229.2414.15.0-229.241
linuxlinux_kernel>= 3.5 < 4.14.3274.14.327
linuxlinux_kernel>= 4.15 < 4.19.2964.19.296
linuxlinux_kernel>= 4.20 < 5.4.2585.4.258
linuxlinux_kernel>= 5.11 < 5.15.1355.15.135
linuxlinux_kernel>= 5.16 < 6.1.576.1.57
linuxlinux_kernel>= 5.5 < 5.10.1985.10.198
linuxlinux_kernel>= 6.2 < 6.5.76.5.7

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
vendor_ubuntu5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.