Share: Email | Twitter

ID

VDE-2024-037

Published

2024-07-10 08:00 (CEST)

Last update

2024-07-10 09:35 (CEST)

Vendor(s)

Pepperl+Fuchs SE

Product(s)

Article No° Product Name Affected Version(s)
480986-100000 to 480986-100080 Smart-Ex 02 <= MR10 (S02ROW.EC.01.02.244.00)
70144901 Smart-Ex02BR-ROW-DZ1BRA- ANDC.. <= MR10 (S02ROW.EC.01.02.244.00)
70142279 Smart-Ex02-RUS-DZ2EAC- ANDC00HM <= MR10 (S02ROW.EC.01.02.244.00)
70144900 Smart-Ex02-RUS-DZ2EAC- ANDCES.. <= MR10 (S02ROW.EC.01.02.244.00)
480994-100000 to 480994-100075 SMART-EX 03 <= MR2 (S03ROW.13.00.00.032)

Summary

A critical security vulnerability was discovered in the products, which is caused by the IPv6 stack in the Linux kernel.
The impact of the vulnerability on the affected products may result in

  • Elevation of privileges

Last Update:

30. August 2024 09:21

Weakness

Use After Free  (CWE-416) 

Summary

In the Linux kernel, the following vulnerability has been resolved: net: fix __dst_negative_advice() race __dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF. RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst). Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order. Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves. Note the check against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various callbacks. Many thanks to Clement Lecigne for tracking this issue. This old bug became visible after the blamed commit, using UDP sockets.


Impact

A privileged local attacker can exploit the vulnerability to gain kernel privileges.

Solution

A protective measure is required.

  • Control access for privileged users.
  • Use IPv4 instead of IPv6.
  • Update the products, when an update is available.

The Issue will be fixed with MR11 on Smart-Ex 02 in September 2024.
The Issue will be fixed with MR3 on SMART-EX 03 in August 2024.

Reported by

CERT@VDE coordinated with Pepperl + Fuchs