Plus: The Conti ransomware gang shuts down, Canada bans Huawei and ZTE, and more of the week’s top security news.

As Russia’s full-scale war in Ukraine heads towards its hundredth day, opposition from Ukrainian forces is as strong as ever. At the same time, hacktivists all around the world continue to breach Russian institutions and publish their files and emails. This week one hacktivist collective took a different—and slightly peculiar—approach: launching a service to prank-call Russian government officials. The new website uses leaked details to put two random Russian officials on a call with each other. It obviously won't make any difference to the outcome of the war, but the group that created it hopes the tool will cause some confusion and annoy those in Moscow.

New research from Google’s Threat Analysis Group has delved into the surveillance-for-hire industry and found that spyware vendors are targeting Android devices with zero-day exploits. State-sponsored actors in Egypt, Armenia, Greece, Madagascar, Côte d’Ivoire, Serbia, Spain, and Indonesia have all purchased hacking tools from the North Macedonian firm Cytrox, the Google team says. The malware has used five previously unknown Android exploits, alongside unpatched vulnerabilities. Overall, Google’s researchers say they’re tracking more than 30 surveillance-for-hire firms around the world.

In other malware news, academics at Germany’s Technical University of Darmstadt have figured out a way to track an iPhone’s location even when it is turned off. When you switch your iPhone off it doesn’t fully power down—instead chips inside run in a low-power mode. The researchers were able to run malware that can track the phone in this low-power mode. They believe their work is the first of its kind, but the method is unlikely to be much of a threat in the real world, as it first requires jailbreaking the targeted iPhone, which has generally become harder to do in recent years.

But wait, there's more. We’ve rounded up all the news that we didn’t break or cover in depth this week. Click on the headlines to read the full stories. And stay safe out there.

International sanctions imposed against North Korea, for its continued development of nuclear weapons and ballistic missiles, mean the nation can’t trade with other countries or bring outside money within its borders. To get around this, in recent years Pyongyang has allowed its state-affiliated hackers to raid cryptocurrency platforms and rob banks. Now the FBI, the US Department of State, and the US Treasury have warned that thousands of North Korea’s IT workers—including app and software developers—have been freelancing at businesses around the world and sending money home. Many of them are based in China or Russia, the officials say. The risks of hiring North Korean workers range from “theft of intellectual property, data, and funds to reputational harm and legal consequences, including sanctions under both US and United Nations authorities.”

In a significant public move, the US Department of Justice says it will stop prosecuting security researchers under the Computer Fraud and Abuse Act. “Computer security research is a key driver of improved cybersecurity,” deputy attorney general Lisa Monaco said in a statement. For years the anti-hacking CFFA law has been criticized for its broad scope and its potential to be abused by prosecutors. While the DOJ’s explicit shift in policy will be welcomed by researchers, as _Motherboard_ reports, the policy doesn’t go far enough and still can put legitimate researchers at risk.

The mostly Russia-based Conti ransomware gang has had a dreadful few months. After backing Vladimir Putin’s war in Ukraine, thousands of its internal messages and innermost secrets were published online. While the gang has continued to target victims, including Costa Rica’s government, researchers now say Conti has officially shut down its operations. Conti’s Tor admin panels have been taken offline, and the group’s members are splintering off into other ransomware groups, according to security firm Advanced Intel. The shutdown comes after the US government offered a $15 million reward for information about Conti's members.

Canada has become the final country in the Five Eyes intelligence group—which also includes the US, UK, Australia, and New Zealand—to ban the use of Huawei’s telecoms equipment in its 5G networks. Fellow Chinese telecom firm ZTE is also included in the ban. The Canadian government, in an announcement, cited national security concerns and the fact that companies could be forced to comply with orders from “foreign governments.” Starting in September, Canadian firms will be banned from buying new 4G and 5G equipment from the Chinese companies. They must remove all existing 5G equipment by the summer of 2024, and 4G equipment must be removed by the end of 2027.

North Korean IT Workers Are Infiltrating Tech Companies

The frame scheduling module has a null pointer dereference vulnerability. Successful exploitation of this vulnerability will affect the kernel availability.

HUAWEI is releasing monthly security updates for flagship models. This security update includes HUAWEI and third-party library patches:

This security update includes the following third-party library patches:

This security update includes the CVE announced in the April 2022 Android security bulletin:

Critical: CVE-2021-35081

High: CVE-2021-0694, CVE-2021-39795, CVE-2021-39803, CVE-2021-39804, CVE-2021-39794, CVE-2021-39796, CVE-2021-39808, CVE-2021-39809, CVE-2021-30334, CVE-2021-35130, CVE-2021-0707, CVE-2021-39800, CVE-2021-39801, CVE-2021-39776

Medium: CVE-2021-39771, CVE-2021-35071, CVE-2021-39739, CVE-2021-39741, CVE-2021-39748, CVE-2021-39759, CVE-2021-39760, CVE-2021-39762, CVE-2021-39763, CVE-2021-39764, CVE-2021-39774, CVE-2021-39777, CVE-2021-39781, CVE-2021-39746, CVE-2021-39757, CVE-2021-39786

Low: none

Already included in previous updates: CVE-2021-30276, CVE-2021-30285, CVE-2021-39690, CVE-2022-20047, CVE-2022-20048, CVE-2021-1918, CVE-2021-30267, CVE-2021-30268, CVE-2021-30269, CVE-2021-30270, CVE-2021-30271, CVE-2021-30273, CVE-2021-30283, CVE-2021-30289, CVE-2021-30293, CVE-2021-30303, CVE-2021-30287, CVE-2021-30300, CVE-2021-30301, CVE-2021-30307, CVE-2021-21781, CVE-2021-39715

※For more information on security patches, please refer to the Android security bulletins (https://source.android.com/security/bulletin).

This security update includes the following HUAWEI patches:

CVE-2021-46785: Improper permission control vulnerability in the Property module

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability can result in the obtaining of the unique device identifier.

Acknowledgment: Zhang Qing (ByteDance), Wang Kailong (NUS), and Bai Guang Dong (UQ)

CVE-2021-46789: Configuration defects in the secure OS module

Severity: Medium

Affected versions: EMUI 11.0.1

Impact: Successful exploitation of this vulnerability will affect availability.

CVE-2021-46788: Third-party pop-up window coverage vulnerability in the iConnect module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.0, EMUI 10.1.1, EMUI 10.1.0, EMUI 10.0.0, Magic UI 4.0.0, Magic UI 3.1.1, Magic UI 3.1.0, Magic UI 3.0.0

Impact: System pop-up window may be covered to mislead users to perform incorrect operations.

CVE-2021-46787: Improper permission control vulnerability in the AMS module

Severity: High

Affected versions: EMUI 11.0.1, EMUI 12.0.0, EMUI 11.0.0, EMUI 10.1.1, EMUI 10.1.0, Magic UI 4.0.0, Magic UI 3.1.1, Magic UI 3.1.0

Impact: Successful exploitation of this vulnerability may cause non-system application processes to crash.

CVE-2021-46786: Insufficient verification of the parameters transferred by the application space in the audio module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1, EMUI 11.0.0, EMUI 10.1.1, EMUI 10.1.0, Magic UI 4.0.0, Magic UI 3.1.1, Magic UI 3.1.0

Impact: Successful exploitation of this vulnerability may cause out-of-bounds memory access.

CVE-2021-40010: Heap overflow vulnerability in the bone voice ID trusted application (TA).

Severity: Critical

Affected versions: EMUI 12.0.0, EMUI 11.0.1, EMUI 11.0.0, EMUI 10.1.1, EMUI 10.1.0, EMUI 10.0.0, Magic UI 4.0.0, Magic UI 3.1.1, Magic UI 3.1.0, Magic UI 3.0.0

Impact: Successful exploitation of this vulnerability may result in malicious code execution.

CVE-2022-22258: Event notification vulnerability in the Wi-Fi module

Severity: Medium

Affected versions: EMUI 10.1.0, EMUI 10.1.1, EMUI 11.0.0, HMOS 2.0.0, Magic UI 3.1.0, Magic UI 3.1.1, Magic UI 4.0.0

Impact: Successful exploitation of this vulnerability may cause third-party apps to intercept and add information and result in elevation-of-privilege.

CVE-2022-29794: UAF vulnerability in the frame scheduling module

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability will affect integrity, availability, and confidentiality.

CVE-2022-22261: Unstrict verification of the validity of the weight in the model in hiaiserver

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability will cause AI service exceptions.

CVE-2022-29793: Configuration defects in the activation lock of the mobile phone

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may affect availability.

CVE-2022-29792: Serial number obtaining vulnerability in the chip assembly

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may affect confidentiality.

CVE-2022-29791: Unstrict verification of the validity of the weight in the model in hiaiserver

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability will cause AI service exceptions.

CVE-2022-29790: Service abnormality caused by multi-threaded access to the database in the graphics acceleration service

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may cause service exceptions.

CVE-2022-29789: Unstrict verification of the validity of the property in the model in hiaiserver

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability will cause AI service exceptions.

CVE-2022-29795: Null pointer dereference vulnerability in the frame scheduling module

Severity: High

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability will affect availability.

CVE-2022-29796: Unstrict verification of the validity of the weight in the model in hiaiserver

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability will cause AI service exceptions.

CVE-2022-22260: UAF vulnerability in the kernel module

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability will affect integrity and availability.

CVE-2022-29795: May

The Property module has a vulnerability in permission control.This vulnerability can be exploited to obtain the unique device identifier.

CVE-2021-46785: May

In CarSetings, there is a possible to pair BT device bypassing user's consent due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12LAndroid ID: A-216190509

_Published May 2, 2022_

The Android Automotive OS (AAOS) Update Bulletin contains details of security vulnerabilities affecting the Android Automotive OS platform. The full AAOS update comprises the security patch level of 2022-05-05 or later from the May 2022 Android Security Bulletin in addition to all issues in this bulletin.

We encourage all customers to accept these updates to their devices.

The issue in this bulletin is a high security vulnerability in the AAOS component that could enable attacker to pair a BT device without the users consent. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.

**Announcements**

*   In addition to the security vulnerabilities described in the May 2022 Android Security Bulletin, the May 2022 Android Automotive OS Update Bulletin also contains patches specifically for AAOS vulnerabilities as described below.

**2022-05-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-05-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as Google Play system updates.

**AAOS**

The vulnerability in this section could enable attacker to pair a BT device without the users consent.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2021-39738

A-216190509

EoP

High

10, 11, 12, 12L

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

To learn how to check a device's security patch level, read the instructions on the Google device update schedule.

*   Security patch levels of 2022-05-01 or later address all issues associated with the 2022-05-01 security patch level.

Device manufacturers that include these updates should set the patch string level to:

*   \[ro.build.version.security\_patch\]:\[2022-05-01\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2022-05-01 security patch level. Please see this article for more details on how to install security updates.

**2\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**3\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.

 

Prefix

Reference

A-

Android bug ID

QC-

Qualcomm reference number

M-

MediaTek reference number

N-

NVIDIA reference number

B-

Broadcom reference number

U-

UNISOC reference number

**4\. What does an \* next to the Android bug ID in the _References_ column mean?**

Issues that are not publicly available have an \* next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**5\. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin?**

Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.

**Versions**

  

Version

Date

Notes

1.0

May 2, 2022

Bulletin Published

CVE-2021-39738: Android Automotive OS Update Bulletin—May 2022  |  Android Open Source Project

In onEntryUpdated of OngoingCallController.kt, it is possible to launch non-exported activities due to intent redirection. This could lead to local escalation of privilege with User execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12 Android-12LAndroid ID: A-212467440

_Published May 2, 2022 | Updated May 3, 2022_

The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2022-05-05 or later address all of these issues. To learn how to check a device's security patch level, see Check and update your Android version.

Android partners are notified of all issues at least a month before publication. Source code patches for these issues will be released to the Android Open Source Project (AOSP) repository in the next 48 hours. We will revise this bulletin with the AOSP links when they are available.

The most severe of these issues is a high security vulnerability in the Framework component that could lead to local escalation of privilege with User execution privileges needed. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.

Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform.

**Android and Google service mitigations**

This is a summary of the mitigations provided by the Android security platform and service protections such as Google Play Protect. These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android.

*   Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible.
*   The Android security team actively monitors for abuse through Google Play Protect and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with Google Mobile Services, and is especially important for users who install apps from outside of Google Play.

**2022-05-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-05-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as Google Play system updates.

**Framework**

The most severe vulnerability in this section could lead to local escalation of privilege with User execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2021-39662

A-197302116

EoP

High

11, 12

CVE-2022-20004

A-179699767

EoP

High

10, 11, 12, 12L

CVE-2022-20005

A-219044664

EoP

High

10, 11, 12, 12L

CVE-2022-20007

A-211481342

EoP

High

10, 11, 12, 12L

CVE-2021-39700

A-201645790

ID

Moderate

10, 11, 12

**System**

The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20113

A-205996517

EoP

High

12, 12L

CVE-2022-20114

A-211114016

EoP

High

10, 11, 12, 12L

CVE-2022-20116

A-212467440

EoP

High

12, 12L

CVE-2022-20010

A-213519176

ID

High

12, 12L

CVE-2022-20011

A-214999128

ID

High

10, 11, 12, 12L

CVE-2022-20115

A-210118427

ID

High

12, 12L

CVE-2021-39670

A-204087139

DoS

High

12, 12L

CVE-2022-20112

A-206987762

DoS

High

10, 11, 12, 12L

**Google Play system updates**

The following issues are included in Project Mainline components.

 

Component

CVE

MediaProvider

CVE-2021-39662

**2022-05-05 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-05-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID.

**Kernel components**

The most severe vulnerability in this section could lead to local escalation of privilege in system libraries with no additional execution privileges needed.

    

CVE

References

Type

Severity

Component

CVE-2022-0847

A-220741611  
Upstream kernel \[2\] \[3\]

EoP

High

pipes

CVE-2022-20009

A-213172319  
Upstream kernel \[2\]

EoP

High

Linux

CVE-2022-20008

A-216481035  
Upstream kernel \[2\] \[3\]

ID

High

SD MMC

CVE-2021-22600

A-213464034  
Upstream kernel

EoP

Moderate

Kernel

**MediaTek components**

These vulnerabilities affect MediaTek components and further details are available directly from MediaTek. The severity assessment of these issues is provided directly by MediaTek.

   

CVE

References

Severity

Component

CVE-2022-20084

A-223071148  
M-ALPS06498874 \*

High

telephony

CVE-2022-20109

A-223072269  
M-ALPS06399915 \*

High

ion

CVE-2022-20110

A-223071150  
M-ALPS06399915 \*

High

ion

**Qualcomm components**

These vulnerabilities affect Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

   

CVE

References

Severity

Component

CVE-2022-22057

A-218337595  
QC-CR#3077687

High

Display

CVE-2022-22064

A-218338071  
QC-CR#3042282  
QC-CR#3048959  
QC-CR#3056532  
QC-CR#3049158 \[2\]

High

WLAN

CVE-2022-22065

A-218337597  
QC-CR#3042293  
QC-CR#3064612

High

WLAN

CVE-2022-22068

A-218337596  
QC-CR#3084983 \[2\]

High

Kernel

CVE-2022-22072

A-218339149  
QC-CR#3073345 \[2\]

High

WLAN

**Qualcomm closed-source components**

These vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

   

CVE

References

Severity

Component

CVE-2021-35090

A-204905205\*

Critical

Closed-source component

CVE-2021-35072

A-204905110\*

High

Closed-source component

CVE-2021-35073

A-204905209\*

High

Closed-source component

CVE-2021-35076

A-204905151\*

High

Closed-source component

CVE-2021-35078

A-204905326\*

High

Closed-source component

CVE-2021-35080

A-204905287\*

High

Closed-source component

CVE-2021-35086

A-204905289\*

High

Closed-source component

CVE-2021-35087

A-204905111\*

High

Closed-source component

CVE-2021-35094

A-204905838\*

High

Closed-source component

CVE-2021-35096

A-204905290\*

High

Closed-source component

CVE-2021-35116

A-209469826\*

High

Closed-source component

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

To learn how to check a device's security patch level, see Check and update your Android version.

*   Security patch levels of 2022-05-01 or later address all issues associated with the 2022-05-01 security patch level.
*   Security patch levels of 2022-05-05 or later address all issues associated with the 2022-05-05 security patch level and all previous patch levels.

Device manufacturers that include these updates should set the patch string level to:

*   \[ro.build.version.security\_patch\]:\[2022-05-01\]
*   \[ro.build.version.security\_patch\]:\[2022-05-05\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2022-05-01 security patch level. Please see this article for more details on how to install security updates.

**2\. Why does this bulletin have two security patch levels?**

This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.

*   Devices that use the 2022-05-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins.
*   Devices that use the security patch level of 2022-05-05 or newer must include all applicable patches in this (and previous) security bulletins.

Partners are encouraged to bundle the fixes for all issues they are addressing in a single update.

**3\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**4\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.

 

Prefix

Reference

A-

Android bug ID

QC-

Qualcomm reference number

M-

MediaTek reference number

N-

NVIDIA reference number

B-

Broadcom reference number

U-

UNISOC reference number

**5\. What does an \* next to the Android bug ID in the _References_ column mean?**

Issues that are not publicly available have an \* next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**6\. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin?**

Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.

**Versions**

  

Version

Date

Notes

1.0

May 2, 2022

Bulletin Published

1.1

May 3, 2022

Bulletin revised to include AOSP links

CVE-2022-20116: Android Security Bulletin—May 2022  |  Android Open Source Project

In getAvailabilityStatus of PrivateDnsPreferenceController.java, there is a possible way for a guest user to change private DNS settings due to a permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12LAndroid ID: A-206987762

CVE-2022-20112: Android Security Bulletin—May 2022  |  Android Open Source Project

NCSC proposes new code of conduct for app stores

NCSC proposes new code of conduct for app stores

  

A report from the UK government has laid bare the risks of malicious mobile apps, as lawmakers call for tougher protections for consumers.

The report (PDF), published by the UK National Cyber Security Centre (NCSC), found that “people’s data and money are at risk because of fraudulent apps containing malicious malware created by cybercriminals or poorly developed apps which can be compromised by hackers exploiting weaknesses in software”.

The study, which conducted a review into the app store ecosystem from December 2020 to March 2022, detailed how 87% of UK citizens now own a smartphone, conveying a widespread attack surface.

Read more of the latest security news from the UK

“\[M\]alicious and poorly developed apps continue to be accessible to users, therefore it is evident that some developers are not following best practice when creating apps,” the NCSC claims.

“Additionally, prominent app store operators are not adequately signposting app requirements to developers and providing detailed feedback if an app or update is rejected.”

**New rules**

In response to the findings, the government is calling views from the tech industry on enhanced security and privacy requirements for firms running app stores and developers making apps.

Under new proposals, app stores for smartphones, game consoles, TVs and other smart devices could be asked to commit to a new code of practice setting out baseline security and privacy requirements, which the UK says “would be the first such measure in the world”.

RELATED UK government reveals plans to become ‘global cyber power’ in 2022

Developers and store operators making apps available to UK users would be covered including Apple, Google, Amazon, Huawei, Microsoft, and Samsung.

The proposed policy would require stores to have a vulnerability reporting process for each app available. They would also be required to share more security and privacy information in an accessible way, including giving consumers information on matters such as why an app would need access to users’ contacts and location.

NCSC technical director Ian Levy commented: “Our threat report shows there is more for app stores to do, with cybercriminals currently using weaknesses in app stores on all types of connected devices to cause harm.

“I support the proposed code of practice, which demonstrates the UK’s continued intent to fix systemic cybersecurity issues.”

**‘Crucial awareness’**

Filip Verloy, EMEA technical evangelist at Noname Security, commented: “These types of initiatives raise crucial awareness of the security issues that we currently face and provide a healthy and necessary debate on the subject. This should prove useful even if it only accomplishes just that.

“However, there are a few flaws to the measures proposed. Firstly, Apple has already made it a point of differentiation to prioritize privacy and security and perform extensive moderation in their app store versus competitors.

“Secondly, there is no such thing as 100% certainty about security when it comes to software, though laying out best practices and increasing scrutiny will certainly help weed out the worst offenders.”

YOU MAY ALSO LIKE UK government employees receive ‘billions’ of malicious emails per year – report

UK government calls for tougher protections against malicious mobile apps

The US has to adapt its own policies to counter the push, warns former DocuSign CEO and Under Secretary of State Keith Krach.

Despite the block on information flowing from China, stories about the nation's surveillance state have leaked out. From social credit scores and online censorship to electronic billboards that display a citizen's "violations" like jaywalking, surveillance is a part of everyday life for millions of Chinese people.

China is increasingly exporting not only its technology but the authoritarian values that underpin them, and this spread must be contained before it moves through more of the world, says Keith Krach, who served as DocuSign CEO from 2009 to 2019 before becoming Under Secretary of State for Economic Growth, Energy, and the Environment in the Trump administration in June 2019.

Krach, who continues to advise the administration of President Joe Biden and leads the Krach Institute for Tech Diplomacy at Purdue University, was nominated for the 2022 Nobel Peace Prize for his work on China. He recently spoke with Dark Reading about China's tech-centered authoritarianism, how the country is embedding its values in its exports, and what the US must do with its own tech policies to keep a moral high ground.

This interview has been condensed for length and clarity.

    

Source: Keith Krach

**Q: You've dedicated much of your career to fighting against "techno-authoritarianism." How do you define that term? What activities rise to the level of authoritarianism?**

**Krach:** Our rivals are playing the long game in what's a four-dimensional game of military, economic, diplomatic, and cultural chess — and the crossroads, the main battleground, is technology. It all intersects there. So here's what techno-authoritarianism is in the simplest \[terms\]: It is using technology for bad instead of for good. That could be a surveillance state, dangerous military weapons, or whatever else is done for bad.

You can think of it as sort of the opposite of what we \[in the United States\] honor as a nation and in the free world at large: respecting things like the rule of law, property of all kinds, nations' sovereignty, human rights, the environment, the press. Those good principles of collaboration, like transparency, reciprocity, accountability — these are things that we honor.

But these are things that China, Russia, the authoritarians don't live by. Instead they \[rule by\] a power principle: cooperation, coercion, concealment, intimidation, retaliation, retribution. And what \[affects us all\] is that when someone doesn't play by the rules, it's no longer a free market; it's a fool's market. For example, let's say you're a Silicon Valley CEO, and I'm a Chinese company. I can steal your intellectual property, I don't have to be transparent, I can use slave labor, I can use cheap energy from big coal-fired power plants.

I don't have to obey the law — or to be \[more precise\], I _am_ the law. How can you possibly compete? I'll beat you every time. So we've got to do something about it.

**Q: You've been particularly vocal about techno-authoritarianism in China — to the extent that you can no longer visit or do business there after officials sanctioned you and your family** **\[among other former Trump officials\] last year.**

**Can you provide context on the extent of Chinese surveillance? It's especially present in Xinjiang, where authorities closely track the habits and activities of millions of Uyghurs, a Muslim minority group in the city. The US is among several countries to accuse China of committing genocide** **of the Uyghurs, but surveillance happens all over the country in varying degrees.**

**Krach:** Oh, it's literally George Orwell's _1984_. They use technology to intimidate, and there is no privacy anymore. To the extent that in Beijing and a lot of the big cities, they have these big TV-like electronic billboards where they show, for example, if somebody jaywalks crossing the street. They'll flash your picture up there, they'll show how many violations they have, all this kind of personal stuff. They know exactly where people are doing, what people are spending, I mean ... everything. They assign people social credit scores based on their behavior and decide what you can and can't do.

It creates a paranoid society where everybody feels watched, and nobody trusts anyone — because there's also incentives for turning people in for violations. It's just a nasty, nasty way to live.

**Q: Chinese authorities, of course, say this surveillance is for the good of the people. They're leveraging technology in all sorts of new projects, including so-called safe cities** **underpinned by \[Chinese telecom\] Huawei that harness all kinds of data about people's activities — ostensibly created to be like what we call smart cities here, helping get ambulances to car accidents faster and assisting police in stopping crime. But in actuality, according to groups like the bipartisan Center for Strategic and International Studies, they're tracking facial recognition and license plate data, monitoring social media, and stomping out dissent.**

**Krach:** These wired cities are a Trojan horse, the same way that what they're doing in Xinjiang is a proving ground. It's beta testing for all this stuff to roll out in China and to export elsewhere. So Xinjiang is literally a glance into the future.

China is essentially exporting a "dictatorship-in-a-box" when they send their surveillance tools \[overseas\]. These are tools that the worst of dictators could have only dreamed up. And that's the stuff that enables genocide: the whole surveillance state, literally thought control. I call it China's Great One-Way Firewall, where all the data comes in for their own use. Propaganda goes out, but the truth does not come in. That's why \[China's President\] Xi \[Jinping\] is just obsessed with technology. His biggest obsession is the semiconductor business because he knows that's the foundation of everything.

**Q: Several countries, including Kyrgyzstan and Ecuador, have adopted Chinese-made surveillance tech. That's in part because China has worked to offer less-funded governments functional and more affordable semiconductors and 5G technologies. When China exports this technology, it seems that in many cases they're exporting the values behind them as well. How can that spread of authoritarianism be stopped?**  

**Krach:** I'll take you inside what happened with 5G for an example. You heard about the 5G race all the time a couple of years ago because it looked like China's most important \[tech\] company Huawei was going to run the table for 5G. They announced 91 5G deals, 47 in Europe. So \[in the US government\] we're hitting the panic button. 5G controls are much more than cell phones: It's utility grids, Internet of Things, people's personal data, the government's more precious secrets.

Right around February 2020 \[when I was Under Secretary of State for Economic Growth, Energy, and the Environment in the Trump administration\], it seemed US efforts to stop it were failing. So our team got the authority to make a last-ditch effort to defeat their 5G master plan. We combined our team with some of the greatest Foreign Service officers, and it was like magic with that diversity of thought.

What we heard was that \[US\] government guys going around the world, saying, "Don't buy Huawei." And I go, "That's the dumbest thing I've ever heard." If I'm a CEO, I'd say to my chief of staff, "Hey, let's check out Huawei. They must have something good." So I said, "Why don't we treat the countries, the telcos, like customers? The customer's always right, and to get a customer, you must have a value proposition. Why should they partner with us if they don't get anything out of it?"

In my first 60 bilateral \[meetings\] I had as under secretary, I asked all these governments, "How's your relationship with China?" They'd say, "Oh, they're a really important trading partner." And then they'd look both ways, as if someone was there, and add, "But we don't trust them." That rang bells in my head. Because trust is the basis of every relationship — personal, business, or otherwise. You buy from people you trust. You partner with people you trust. So we went around to the CEOs of these foreign telcos and said, "Do you want to give your government's and citizens' data to a country that requires any company to turn information over to the Chinese Communist Party? Or do you want to partner with someone you trust?"

We created a digital standard of trust, called the Trust Principle, built on principles like respect for human rights and collaboration. And that was the basis for what we did with the Clean Network, a group of 60 countries that represent two-thirds of the world's global GDP, \[along with\] 200 telcos and a whole host of companies that were committed to building a 5G system completely free of bad actors and dedicated to fair principles.

It's not an anti-China thing. It's your choice: You can either be locked out of 70% of the market, or you can change the way that you do business. That moral high ground is key. In one move, we took those things that they were using against us and weaponized the very principles that protect our freedoms. In less than a year, those 91 \[Huawei\] 5G deals dropped by \[dozens and dozens\].

    

Source: Keith Krach

**Q. I want to turn the lens inward now because ideas like the Trust Principle and the Clean Network depend on maintaining that moral high ground — and they're built on essentially what we think of as fundamental American ideals — but in reality, the US has participated in surveillance itself. And in the private sector, plenty of US tech companies have had their own issues with data privacy and security, with many of their businesses based on supplying free services and monetizing the data their users provide. Can we have a leg to stand on unless we reform our own practices here in the States?**

**Krach:** It's an interesting and important question. Most people have never heard of this position, but I was the US/EU ombudsman for the data privacy shield. Now what that meant was after the Snowden episode, the Europeans go, "You know, we don't want you guys to do it again." And so they came up with a one-way data privacy shield: From a governance standpoint, if the United States snooped on a European and the Europeans found out about it, then they had a mechanism where they take it to the EU, they'd sort it out, and then it would come directly to me. There was nobody in the executive branch overseeing me on this, to be honest — it was straight with the judicial branch, and those guys were serious. "We're gonna prosecute come hell or high water. Patriotism thrown out the door; you've got to do what's right." And that was an interesting thing.

But the first thing I thought was, why isn't this reciprocal? The No. 1 thing \[I said\] when I met with the Europeans was, "Why is this a one-way thing, but you guys are shielded?" And then I'd say, "Oh, hey, how's your EU/China data privacy shield going? You have one, right?" And they're like, "Uh ... no. You know, China will be China."

Anyway, from a company standpoint, when people think of US tech companies, they think of the social and search companies like Google and Facebook. They're important companies, sure, but that's a small fraction of it. In my view, the rules of the road have not fully been written yet on data, privacy, security, data flows. It's going to take not only all three branches of our government but also the private sector and international players. If I were \[a tech CEO\], I would get out in front of this one because you can see it's going to be coming down. Things like Elon Musk buying Twitter probably would be a catalyst for that.

**Q: What, then, does the US need to do? It sounds like you think there's a lot more coming pretty soon down the pipe in terms of regulatory and compliance.**

**Krach:** Yeah, yeah. And I think it needs to be clear. But also, US companies were getting robbed blind and locked out of the Chinese market. So there's a squeeze play there, and then \[on the government level\] the EU was coming up with these regulations that just target US companies, so there's another squeeze play. But here again, it all boils down to one word: trust. You have to be able to trust the people you partner with, and you have to be trusted yourself.

**Q: As we look at how technology is evolving in general — Web3, the metaverse — there's so much emerging. Which security issues do you think should be top of mind from a policy standpoint?**

**Krach:** The first one is protect from the enemy. On _60 Minutes_, FBI Director \[Christopher\] Wray talked at length about China's cyber threat and threat to intellectual property. Because their attitude is, if it's out there and we can take it, it's your fault for not protecting it. It's a wholly different value system. 

So the second piece is educating everyone about that, especially at the corporate board level. I just wrote an article for Fortune about how companies need to have their China contingency plan. \[Business leaders\] need to ask themselves, "What is our policy to make sure that we're trusted by our customers, our shareholders, our suppliers, our partners, all the governments we do business with?"

There's some things the government can help out on. For example, we could install something like the no-bribery law, in which American companies that go overseas and are asked for bribes have the law to fall back on. They can say, "No can do, it's against the law. I'll go to jail, sorry." Why don't we make a law that it's illegal to transfer technology to the Chinese? They have that divide-and-conquer system: "You guys won't give it to me? I'll go to your competitor." So there's some things that we can do along those lines, understanding their values and how we can weaponize ours. But again here, it takes collaboration across government and the private sector. It's critical that we figure it out.

Q&A: How China Is Exporting Tech-Based Authoritarianism Across the World

jbd2_journal_wait_updates in fs/jbd2/transaction.c in the Linux kernel before 5.17.1 has a use-after-free caused by a transaction_t race condition.

CVE-2022-28796

A use-after-free read flaw was found in sock_getsockopt() in net/core/sock.c due to SO_PEERCRED and SO_PEERGROUPS race with listen() (and connect()) in the Linux kernel. In this flaw, an attacker with a user privileges may crash the system or leak internal kernel information.

\* **\[PATCH net\] af\_unix: fix races in sk\_peer\_pid and sk\_peer\_cred accesses**
**@ 2021-09-29 22:57 Eric Dumazet**
  2021-09-30 13:30 \` patchwork-bot+netdevbpf
  2022-03-24  8:03 \` wanghai (M)
  0 siblings, 2 replies; 5+ messages in thread
From: Eric Dumazet @ 2021-09-29 22:57 UTC (permalink / raw)
  To: David S . Miller, Jakub Kicinski
  Cc: netdev, Eric Dumazet, Eric Dumazet, Jann Horn,
	Eric W . Biederman, Luiz Augusto von Dentz, Marcel Holtmann

From: Eric Dumazet <edumazet@google.com>

Jann Horn reported that SO\_PEERCRED and SO\_PEERGROUPS implementations
are racy, as af\_unix can concurrently change sk\_peer\_pid and sk\_peer\_cred.

In order to fix this issue, this patch adds a new spinlock that needs
to be used whenever these fields are read or written.

Jann also pointed out that l2cap\_sock\_get\_peer\_pid\_cb() is currently
reading sk->sk\_peer\_pid which makes no sense, as this field
is only possibly set by AF\_UNIX sockets.
We will have to clean this in a separate patch.
This could be done by reverting b48596d1dc25 "Bluetooth: L2CAP: Add get\_peer\_pid callback"
or implementing what was truly expected.

Fixes: 109f6e39fa07 ("af\_unix: Allow SO\_PEERCRED to work across namespaces.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Jann Horn <jannh@google.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
---
 include/net/sock.h |  2 ++
 net/core/sock.c    | 32 ++++++++++++++++++++++++++------
 net/unix/af\_unix.c | 34 ++++++++++++++++++++++++++++------
 3 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index c005c3c750e89b6d4d36d36ccfad392a7e733603..f471cd0a6f98cb5b2b961f01c2de62870d61521e 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -488,8 +488,10 @@ struct sock {
 	u8			sk\_prefer\_busy\_poll;
 	u16			sk\_busy\_poll\_budget;
 #endif
+	spinlock\_t		sk\_peer\_lock;
 	struct pid		\*sk\_peer\_pid;
 	const struct cred	\*sk\_peer\_cred;
+
 	long			sk\_rcvtimeo;
 	ktime\_t			sk\_stamp;
 #if BITS\_PER\_LONG==32
diff --git a/net/core/sock.c b/net/core/sock.c
index 512e629f97803f3216db8f054e97fd1b7a6e6c63..c70cbce69a66181c3688862ea51aa781b3ce4f97 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1376,6 +1376,16 @@ int sock\_setsockopt(struct socket \*sock, int level, int optname,
 }
 EXPORT\_SYMBOL(sock\_setsockopt);
 
+static const struct cred \*sk\_get\_peer\_cred(struct sock \*sk)
+{
+	const struct cred \*cred;
+
+	spin\_lock(&sk->sk\_peer\_lock);
+	cred = get\_cred(sk->sk\_peer\_cred);
+	spin\_unlock(&sk->sk\_peer\_lock);
+
+	return cred;
+}
 
 static void cred\_to\_ucred(struct pid \*pid, const struct cred \*cred,
 			  struct ucred \*ucred)
@@ -1552,7 +1562,11 @@ int sock\_getsockopt(struct socket \*sock, int level, int optname,
 		struct ucred peercred;
 		if (len > sizeof(peercred))
 			len = sizeof(peercred);
+
+		spin\_lock(&sk->sk\_peer\_lock);
 		cred\_to\_ucred(sk->sk\_peer\_pid, sk->sk\_peer\_cred, &peercred);
+		spin\_unlock(&sk->sk\_peer\_lock);
+
 		if (copy\_to\_user(optval, &peercred, len))
 			return -EFAULT;
 		goto lenout;
@@ -1560,20 +1574,23 @@ int sock\_getsockopt(struct socket \*sock, int level, int optname,
 
 	case SO\_PEERGROUPS:
 	{
+		const struct cred \*cred;
 		int ret, n;
 
\-		if (!sk->sk\_peer\_cred)
+		cred = sk\_get\_peer\_cred(sk);
+		if (!cred)
 			return -ENODATA;
 
\-		n = sk->sk\_peer\_cred->group\_info->ngroups;
+		n = cred->group\_info->ngroups;
 		if (len < n \* sizeof(gid\_t)) {
 			len = n \* sizeof(gid\_t);
+			put\_cred(cred);
 			return put\_user(len, optlen) ? -EFAULT : -ERANGE;
 		}
 		len = n \* sizeof(gid\_t);
 
\-		ret = groups\_to\_user((gid\_t \_\_user \*)optval,
-				     sk->sk\_peer\_cred->group\_info);
+		ret = groups\_to\_user((gid\_t \_\_user \*)optval, cred->group\_info);
+		put\_cred(cred);
 		if (ret)
 			return ret;
 		goto lenout;
@@ -1935,9 +1952,10 @@ static void \_\_sk\_destruct(struct rcu\_head \*head)
 		sk->sk\_frag.page = NULL;
 	}
 
\-	if (sk->sk\_peer\_cred)
-		put\_cred(sk->sk\_peer\_cred);
+	/\* We do not need to acquire sk->sk\_peer\_lock, we are the last user. \*/
+	put\_cred(sk->sk\_peer\_cred);
 	put\_pid(sk->sk\_peer\_pid);
+
 	if (likely(sk->sk\_net\_refcnt))
 		put\_net(sock\_net(sk));
 	sk\_prot\_free(sk->sk\_prot\_creator, sk);
@@ -3145,6 +3163,8 @@ void sock\_init\_data(struct socket \*sock, struct sock \*sk)
 
 	sk->sk\_peer\_pid 	=	NULL;
 	sk->sk\_peer\_cred	=	NULL;
+	spin\_lock\_init(&sk->sk\_peer\_lock);
+
 	sk->sk\_write\_pending	=	0;
 	sk->sk\_rcvlowat		=	1;
 	sk->sk\_rcvtimeo		=	MAX\_SCHEDULE\_TIMEOUT;
diff --git a/net/unix/af\_unix.c b/net/unix/af\_unix.c
index f505b89bda6adefe973806f842001d428fc6c5ca..efac5989edb5d37881139bb1ad2fb9cf63bd7342 100644
--- a/net/unix/af\_unix.c
+++ b/net/unix/af\_unix.c
@@ -608,20 +608,42 @@ static void unix\_release\_sock(struct sock \*sk, int embrion)
 
 static void init\_peercred(struct sock \*sk)
 {
\-	put\_pid(sk->sk\_peer\_pid);
-	if (sk->sk\_peer\_cred)
-		put\_cred(sk->sk\_peer\_cred);
+	const struct cred \*old\_cred;
+	struct pid \*old\_pid;
+
+	spin\_lock(&sk->sk\_peer\_lock);
+	old\_pid = sk->sk\_peer\_pid;
+	old\_cred = sk->sk\_peer\_cred;
 	sk->sk\_peer\_pid  = get\_pid(task\_tgid(current));
 	sk->sk\_peer\_cred = get\_current\_cred();
+	spin\_unlock(&sk->sk\_peer\_lock);
+
+	put\_pid(old\_pid);
+	put\_cred(old\_cred);
 }
 
 static void copy\_peercred(struct sock \*sk, struct sock \*peersk)
 {
\-	put\_pid(sk->sk\_peer\_pid);
-	if (sk->sk\_peer\_cred)
-		put\_cred(sk->sk\_peer\_cred);
+	const struct cred \*old\_cred;
+	struct pid \*old\_pid;
+
+	if (sk < peersk) {
+		spin\_lock(&sk->sk\_peer\_lock);
+		spin\_lock\_nested(&peersk->sk\_peer\_lock, SINGLE\_DEPTH\_NESTING);
+	} else {
+		spin\_lock(&peersk->sk\_peer\_lock);
+		spin\_lock\_nested(&sk->sk\_peer\_lock, SINGLE\_DEPTH\_NESTING);
+	}
+	old\_pid = sk->sk\_peer\_pid;
+	old\_cred = sk->sk\_peer\_cred;
 	sk->sk\_peer\_pid  = get\_pid(peersk->sk\_peer\_pid);
 	sk->sk\_peer\_cred = get\_cred(peersk->sk\_peer\_cred);
+
+	spin\_unlock(&sk->sk\_peer\_lock);
+	spin\_unlock(&peersk->sk\_peer\_lock);
+
+	put\_pid(old\_pid);
+	put\_cred(old\_cred);
 }
 
 static int unix\_listen(struct socket \*sock, int backlog)
-- 
2.33.0.800.g4c38ced690-goog

^ permalink raw reply	\[**flat**|nested\] 5+ messages in thread

\* **Re: \[PATCH net\] af\_unix: fix races in sk\_peer\_pid and sk\_peer\_cred accesses**
  2021-09-29 22:57 \[PATCH net\] af\_unix: fix races in sk\_peer\_pid and sk\_peer\_cred accesses Eric Dumazet
**@ 2021-09-30 13:30 \` patchwork-bot+netdevbpf**
  2022-03-24  8:03 \` wanghai (M)
  1 sibling, 0 replies; 5+ messages in thread
From: patchwork-bot+netdevbpf @ 2021-09-30 13:30 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: davem, kuba, netdev, edumazet, jannh, ebiederm, luiz.von.dentz, marcel

Hello:

This patch was applied to netdev/net.git (refs/heads/master):

On Wed, 29 Sep 2021 15:57:50 -0700 you wrote:
\> From: Eric Dumazet <edumazet@google.com>
> 
> Jann Horn reported that SO\_PEERCRED and SO\_PEERGROUPS implementations
> are racy, as af\_unix can concurrently change sk\_peer\_pid and sk\_peer\_cred.
> 
> In order to fix this issue, this patch adds a new spinlock that needs
> to be used whenever these fields are read or written.
> 
> \[...\]
Here is the summary with links:
  - \[net\] af\_unix: fix races in sk\_peer\_pid and sk\_peer\_cred accesses
    https://git.kernel.org/netdev/net/c/35306eb23814

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

^ permalink raw reply	\[**flat**|nested\] 5+ messages in thread

\* **Re: \[PATCH net\] af\_unix: fix races in sk\_peer\_pid and sk\_peer\_cred accesses**
  2021-09-29 22:57 \[PATCH net\] af\_unix: fix races in sk\_peer\_pid and sk\_peer\_cred accesses Eric Dumazet
  2021-09-30 13:30 \` patchwork-bot+netdevbpf
**@ 2022-03-24  8:03 \` wanghai (M)**
  2022-03-24  9:04   \` Kuniyuki Iwashima
  1 sibling, 1 reply; 5+ messages in thread
From: wanghai (M) @ 2022-03-24  8:03 UTC (permalink / raw)
  To: Eric Dumazet, David S . Miller, Jakub Kicinski
  Cc: netdev, Eric Dumazet, Jann Horn, Eric W . Biederman,
	Luiz Augusto von Dentz, Marcel Holtmann


在 2021/9/30 6:57, Eric Dumazet 写道:
\> From: Eric Dumazet <edumazet@google.com>
>
> Jann Horn reported that SO\_PEERCRED and SO\_PEERGROUPS implementations
> are racy, as af\_unix can concurrently change sk\_peer\_pid and sk\_peer\_cred.
>
> In order to fix this issue, this patch adds a new spinlock that needs
> to be used whenever these fields are read or written.
>
> Jann also pointed out that l2cap\_sock\_get\_peer\_pid\_cb() is currently
> reading sk->sk\_peer\_pid which makes no sense, as this field
> is only possibly set by AF\_UNIX sockets.
> We will have to clean this in a separate patch.
> This could be done by reverting b48596d1dc25 "Bluetooth: L2CAP: Add get\_peer\_pid callback"
> or implementing what was truly expected.
>
> Fixes: 109f6e39fa07 ("af\_unix: Allow SO\_PEERCRED to work across namespaces.")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Jann Horn <jannh@google.com>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> ---
...
\>   static void copy\_peercred(struct sock \*sk, struct sock \*peersk)
>   {
> -	put\_pid(sk->sk\_peer\_pid);
> -	if (sk->sk\_peer\_cred)
> -		put\_cred(sk->sk\_peer\_cred);
> +	const struct cred \*old\_cred;
> +	struct pid \*old\_pid;
> +
> +	if (sk < peersk) {
> +		spin\_lock(&sk->sk\_peer\_lock);
> +		spin\_lock\_nested(&peersk->sk\_peer\_lock, SINGLE\_DEPTH\_NESTING);
> +	} else {
> +		spin\_lock(&peersk->sk\_peer\_lock);
> +		spin\_lock\_nested(&sk->sk\_peer\_lock, SINGLE\_DEPTH\_NESTING);
> +	}
Hi, ALL.
I'm sorry to bother you.

This patch adds sk\_peer\_lock to solve the problem that af\_unix may
concurrently change sk\_peer\_pid and sk\_peer\_cred.

I am confused as to why the order of locks is needed here based on
the address size of sk and peersk.

Any feedback would be appreciated, thanks.
\> +	old\_pid = sk->sk\_peer\_pid;
> +	old\_cred = sk->sk\_peer\_cred;
>   	sk->sk\_peer\_pid  = get\_pid(peersk->sk\_peer\_pid);
>   	sk->sk\_peer\_cred = get\_cred(peersk->sk\_peer\_cred);
> +
> +	spin\_unlock(&sk->sk\_peer\_lock);
> +	spin\_unlock(&peersk->sk\_peer\_lock);
> +
> +	put\_pid(old\_pid);
> +	put\_cred(old\_cred);
>   }
>   
>   static int unix\_listen(struct socket \*sock, int backlog)
-- 
Wang Hai

^ permalink raw reply	\[**flat**|nested\] 5+ messages in thread

\* **Re: \[PATCH net\] af\_unix: fix races in sk\_peer\_pid and sk\_peer\_cred accesses**
  2022-03-24  8:03 \` wanghai (M)
**@ 2022-03-24  9:04   \` Kuniyuki Iwashima**
  2022-03-24 11:15     \` wanghai (M)
  0 siblings, 1 reply; 5+ messages in thread
From: Kuniyuki Iwashima @ 2022-03-24  9:04 UTC (permalink / raw)
  To: wanghai38
  Cc: davem, ebiederm, edumazet, eric.dumazet, jannh, kuba,
	luiz.von.dentz, marcel, netdev

From:   "wanghai (M)" <wanghai38@huawei.com>
Date:   Thu, 24 Mar 2022 16:03:31 +0800
\> 在 2021/9/30 6:57, Eric Dumazet 写道:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> Jann Horn reported that SO\_PEERCRED and SO\_PEERGROUPS implementations
>> are racy, as af\_unix can concurrently change sk\_peer\_pid and sk\_peer\_cred.
>>
>> In order to fix this issue, this patch adds a new spinlock that needs
>> to be used whenever these fields are read or written.
>>
>> Jann also pointed out that l2cap\_sock\_get\_peer\_pid\_cb() is currently
>> reading sk->sk\_peer\_pid which makes no sense, as this field
>> is only possibly set by AF\_UNIX sockets.
>> We will have to clean this in a separate patch.
>> This could be done by reverting b48596d1dc25 "Bluetooth: L2CAP: Add get\_peer\_pid callback"
>> or implementing what was truly expected.
>>
>> Fixes: 109f6e39fa07 ("af\_unix: Allow SO\_PEERCRED to work across namespaces.")
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Reported-by: Jann Horn <jannh@google.com>
>> Cc: Eric W. Biederman <ebiederm@xmission.com>
>> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>> Cc: Marcel Holtmann <marcel@holtmann.org>
>> ---
> ...
>>   static void copy\_peercred(struct sock \*sk, struct sock \*peersk)
>>   {
>> -	put\_pid(sk->sk\_peer\_pid);
>> -	if (sk->sk\_peer\_cred)
>> -		put\_cred(sk->sk\_peer\_cred);
>> +	const struct cred \*old\_cred;
>> +	struct pid \*old\_pid;
>> +
>> +	if (sk < peersk) {
>> +		spin\_lock(&sk->sk\_peer\_lock);
>> +		spin\_lock\_nested(&peersk->sk\_peer\_lock, SINGLE\_DEPTH\_NESTING);
>> +	} else {
>> +		spin\_lock(&peersk->sk\_peer\_lock);
>> +		spin\_lock\_nested(&sk->sk\_peer\_lock, SINGLE\_DEPTH\_NESTING);
>> +	}
> Hi, ALL.
> I'm sorry to bother you.
> 
> This patch adds sk\_peer\_lock to solve the problem that af\_unix may
> concurrently change sk\_peer\_pid and sk\_peer\_cred.
> 
> I am confused as to why the order of locks is needed here based on
> the address size of sk and peersk.
To simply avoid dead lock.  These locks must be acquired in the same
order.  The smaller address lock is acquired first, then larger one.

  e.g.) CPU-A calls copy\_peercred(sk-A, sk-B), and
        CPU-B calls copy\_peercred(sk-B, sk-A).

There are some implementations like this:

  $ grep -rn double\_lock

\> 
> Any feedback would be appreciated, thanks.
>> +	old\_pid = sk->sk\_peer\_pid;
>> +	old\_cred = sk->sk\_peer\_cred;
>>   	sk->sk\_peer\_pid  = get\_pid(peersk->sk\_peer\_pid);
>>   	sk->sk\_peer\_cred = get\_cred(peersk->sk\_peer\_cred);
>> +
>> +	spin\_unlock(&sk->sk\_peer\_lock);
>> +	spin\_unlock(&peersk->sk\_peer\_lock);
>> +
>> +	put\_pid(old\_pid);
>> +	put\_cred(old\_cred);
>>   }
>>   
>>   static int unix\_listen(struct socket \*sock, int backlog)
> 
> -- 
> Wang Hai
^ permalink raw reply	\[**flat**|nested\] 5+ messages in thread

\* **Re: \[PATCH net\] af\_unix: fix races in sk\_peer\_pid and sk\_peer\_cred accesses**
  2022-03-24  9:04   \` Kuniyuki Iwashima
**@ 2022-03-24 11:15     \` wanghai (M)**
  0 siblings, 0 replies; 5+ messages in thread
From: wanghai (M) @ 2022-03-24 11:15 UTC (permalink / raw)
  To: Kuniyuki Iwashima
  Cc: davem, ebiederm, edumazet, eric.dumazet, jannh, kuba,
	luiz.von.dentz, marcel, netdev


在 2022/3/24 17:04, Kuniyuki Iwashima 写道:
\> From:   "wanghai (M)" <wanghai38@huawei.com>
> Date:   Thu, 24 Mar 2022 16:03:31 +0800
>> 在 2021/9/30 6:57, Eric Dumazet 写道:
>>> From: Eric Dumazet <edumazet@google.com>
>>>
>>> Jann Horn reported that SO\_PEERCRED and SO\_PEERGROUPS implementations
>>> are racy, as af\_unix can concurrently change sk\_peer\_pid and sk\_peer\_cred.
>>>
>>> In order to fix this issue, this patch adds a new spinlock that needs
>>> to be used whenever these fields are read or written.
>>>
>>> Jann also pointed out that l2cap\_sock\_get\_peer\_pid\_cb() is currently
>>> reading sk->sk\_peer\_pid which makes no sense, as this field
>>> is only possibly set by AF\_UNIX sockets.
>>> We will have to clean this in a separate patch.
>>> This could be done by reverting b48596d1dc25 "Bluetooth: L2CAP: Add get\_peer\_pid callback"
>>> or implementing what was truly expected.
>>>
>>> Fixes: 109f6e39fa07 ("af\_unix: Allow SO\_PEERCRED to work across namespaces.")
>>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>>> Reported-by: Jann Horn <jannh@google.com>
>>> Cc: Eric W. Biederman <ebiederm@xmission.com>
>>> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>>> Cc: Marcel Holtmann <marcel@holtmann.org>
>>> ---
>> ...
>>>    static void copy\_peercred(struct sock \*sk, struct sock \*peersk)
>>>    {
>>> -	put\_pid(sk->sk\_peer\_pid);
>>> -	if (sk->sk\_peer\_cred)
>>> -		put\_cred(sk->sk\_peer\_cred);
>>> +	const struct cred \*old\_cred;
>>> +	struct pid \*old\_pid;
>>> +
>>> +	if (sk < peersk) {
>>> +		spin\_lock(&sk->sk\_peer\_lock);
>>> +		spin\_lock\_nested(&peersk->sk\_peer\_lock, SINGLE\_DEPTH\_NESTING);
>>> +	} else {
>>> +		spin\_lock(&peersk->sk\_peer\_lock);
>>> +		spin\_lock\_nested(&sk->sk\_peer\_lock, SINGLE\_DEPTH\_NESTING);
>>> +	}
>> Hi, ALL.
>> I'm sorry to bother you.
>>
>> This patch adds sk\_peer\_lock to solve the problem that af\_unix may
>> concurrently change sk\_peer\_pid and sk\_peer\_cred.
>>
>> I am confused as to why the order of locks is needed here based on
>> the address size of sk and peersk.
> To simply avoid dead lock.  These locks must be acquired in the same
> order.  The smaller address lock is acquired first, then larger one.
>
>    e.g.) CPU-A calls copy\_peercred(sk-A, sk-B), and
>          CPU-B calls copy\_peercred(sk-B, sk-A).
>
> There are some implementations like this:
>
>    $ grep -rn double\_lock
I got it, thank you for your patient explanation.
\>
>
>> Any feedback would be appreciated, thanks.
>>> +	old\_pid = sk->sk\_peer\_pid;
>>> +	old\_cred = sk->sk\_peer\_cred;
>>>    	sk->sk\_peer\_pid  = get\_pid(peersk->sk\_peer\_pid);
>>>    	sk->sk\_peer\_cred = get\_cred(peersk->sk\_peer\_cred);
>>> +
>>> +	spin\_unlock(&sk->sk\_peer\_lock);
>>> +	spin\_unlock(&peersk->sk\_peer\_lock);
>>> +
>>> +	put\_pid(old\_pid);
>>> +	put\_cred(old\_cred);
>>>    }
>>>    
>>>    static int unix\_listen(struct socket \*sock, int backlog)
>> -- 
>> Wang Hai
> .
>
\-- 
Wang Hai

^ permalink raw reply	\[**flat**|nested\] 5+ messages in thread

end of thread, other threads:\[~2022-03-24 11:15 UTC | newest\]

**Thread overview:** 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-29 22:57 \[PATCH net\] af\_unix: fix races in sk\_peer\_pid and sk\_peer\_cred accesses Eric Dumazet
2021-09-30 13:30 \` patchwork-bot+netdevbpf
2022-03-24  8:03 \` wanghai (M)
2022-03-24  9:04   \` Kuniyuki Iwashima
2022-03-24 11:15     \` wanghai (M)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).

Tag

#huawei