CVE-2024-47659

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smack: tcp: ipv4, fix incorrect labeling<br /> <br /> Currently, Smack mirrors the label of incoming tcp/ipv4 connections:<br /> when a label &amp;#39;foo&amp;#39; connects to a label &amp;#39;bar&amp;#39; with tcp/ipv4,<br /> &amp;#39;foo&amp;#39; always gets &amp;#39;foo&amp;#39; in returned ipv4 packets. So,<br /> 1) returned packets are incorrectly labeled (&amp;#39;foo&amp;#39; instead of &amp;#39;bar&amp;#39;)<br /> 2) &amp;#39;bar&amp;#39; can write to &amp;#39;foo&amp;#39; without being authorized to write.<br /> <br /> Here is a scenario how to see this:<br /> <br /> * Take two machines, let&amp;#39;s call them C and S,<br /> with active Smack in the default state<br /> (no settings, no rules, no labeled hosts, only builtin labels)<br /> <br /> * At S, add Smack rule &amp;#39;foo bar w&amp;#39;<br /> (labels &amp;#39;foo&amp;#39; and &amp;#39;bar&amp;#39; are instantiated at S at this moment)<br /> <br /> * At S, at label &amp;#39;bar&amp;#39;, launch a program<br /> that listens for incoming tcp/ipv4 connections<br /> <br /> * From C, at label &amp;#39;foo&amp;#39;, connect to the listener at S.<br /> (label &amp;#39;foo&amp;#39; is instantiated at C at this moment)<br /> Connection succeedes and works.<br /> <br /> * Send some data in both directions.<br /> * Collect network traffic of this connection.<br /> <br /> All packets in both directions are labeled with the CIPSO<br /> of the label &amp;#39;foo&amp;#39;. Hence, label &amp;#39;bar&amp;#39; writes to &amp;#39;foo&amp;#39; without<br /> being authorized, and even without ever being known at C.<br /> <br /> If anybody cares: exactly the same happens with DCCP.<br /> <br /> This behavior 1st manifested in release 2.6.29.4 (see Fixes below)<br /> and it looks unintentional. At least, no explanation was provided.<br /> <br /> I changed returned packes label into the &amp;#39;bar&amp;#39;,<br /> to bring it into line with the Smack documentation claims.