US lawmakers keep warning about the popular app. But until they can explain what makes it uniquely dangerous, it’s difficult to tailor a resolution.

Amid a flurry of talking points and takedowns as the United States midterm elections loom, lawmakers and regulators have reheated claims about TikTok, a social media app they say poses a threat to personal privacy and US national security. Now, the Biden administration is reportedly readying its own action. But the exact scope of the problem and goals remain fuzzy. Owned by the Chinese tech giant Bytedance, TikTok has more than a billion users, including an estimated 135 million in the US, and some lawmakers, including former president Donald Trump, have warned over the past two years that the Chinese government could use the app to collect data on Americans or launch influence operations through the platform.

The US military banned its members from using TikTok on government devices or at all in late 2019 and early 2020, as did the Transportation Security Administration and some other federal agencies. Just last month, the chief administrative officer for the US House of Representatives warned lawmakers against installing TikTok due to the data it can collect. This followed a June 17 BuzzFeed News report, which found that ByteDance employees can and do gain access to US TikTok users' data in some situations. But for the general public, warnings from legislators and regulators this summer have continued to be vague and amorphous, underscoring broader ambiguity about where lawmakers' precise concerns lie. 

With so many users, TikTok is clearly a potentially rich source of personal data and could be exploited in the way other social platforms have been to spread disinformation or promote influence operations. But the reason TikTok has been singled out is less clear. Huge quantities of sensitive data about people living in the US are already available in various forms for purchase or the taking through other public social media platforms, the digital marketing industry, data brokers, and leaked stolen data troves. And long before the rise of TikTok, China was already notorious on the global stage for stealing massive quantities of data about Americans and others from governments and companies around the world. So, is it protectionism? Xenophobia? Special insight into US national security?

A report published by Semafor on Friday indicates that the Biden administration is preparing a series of executive orders to address TikTok and the Chinese tech sector's access to Americans' data more broadly. The report says the White House's actions could significantly curtail US investment in China, while other potential measures may limit what technology can be sold to Chinese clients and specifically limit the data Chinese tech companies can collect about US citizens.

Such steps would be less dramatic than the approach to TikTok taken by Biden's predecessor but would have a larger scope and wider set of potential ramifications. In the waning months of the Trump administration, the White House attempted to block TikTok from US app stores if ByteDance didn't sell the company to a US-based firm. Though the move failed, TikTok took steps to silo itself from its Chinese owners and announced in June that all US user traffic would be routed in the US. The company is still working on deleting all user data from its own servers in favor of processing everything in Oracle's cloud. The company stores data backups in the US and Singapore.

“The thing about TikTok is that a lot of people use it!” says Rui Zhong, a researcher at the Kissinger Institute on China and the United States. “The Trump administration also tried to ban WeChat, which is not just a communication platform but a technology platform that vacuums up reams of your data—more so than TikTok. But WeChat is almost exclusively used in the US by the Chinese diaspora, whereas TikTok is just broadly popular with Americans.”

She adds that while, from a US national security perspective, the existential threats are worth acknowledging, there wasn't enough information available about concrete concerns when the TikTok ban was on the table a couple of years ago or in remarks this summer. US officials still don't seem, at least publicly, to have a smoking gun illustrating the urgency of the threat. “It needed a better case built around it, and at the time in 2019 they just didn’t seem to have that case,” Zhong says. “Whether they will have something they can show Americans in the future or not, I can’t say.”

On June 24, days after the BuzzFeed report, a group of Republican senators led by Tom Cotton of Arkansas sent a letter to Treasury Secretary Janet Yellen “to inquire about the Biden administration’s delayed response to the national security and privacy risks posed by TikTok.” On June 28, a different group of nine Republican senators sent a letter to TikTok's CEO, Shou Zi Chew, laying out questions about the company's data management practices and relationship with ByteDance given that the company has always maintained that they will not share US user data with the Chinese government. On July 5, a bipartisan duo from the Senate Select Committee on Intelligence—democrat Mark Warner of Virginia and Republican Marco Rubio of Florida—sent a letter to the Federal Trade Commission urging the agency to investigate TikTok and ByteDance for “repeated misrepresentations by TikTok concerning its data security, data processing, and corporate governance practices.”

In a series of responses this summer both to lawmakers and the public, TikTok has staunchly maintained that it does not and would never share US user data with the Chinese government, and that it is a separate US-based entity subject to US laws. The company does not report publicly on government data requests, but it does publish a twice-annual report about government requests to remove content from the service. The latter report indicates that the company has never fulfilled a removal request from China.

The bottom line, though, is that TikTok is owned by ByteDance. And some ByteDance employees can access TikTok user data. Does that mean the ruling Chinese Communist Party (CCP) can get that data too? In his June 30 response to the nine Republican senators, TikTok's Chew said, “Employees outside the US, including China-based employees, can have access to TikTok US user data subject to a series of robust cybersecurity controls and authorization approval protocols overseen by our US-based security team.” He described at length the layers of classification and restriction that protect user data from being accessed casually or without oversight. Chew and TikTok have long maintained that it they “have not provided US user data to the CCP, nor would we if asked.” When WIRED asked TikTok how this squares with the reality that ByteDance has access and could be compelled to exercise it under Chinese law, spokesperson Maureen Shanahan said, “TikTok is provided in the United States by TikTok Inc., which is incorporated in California and subject to US laws and regulations.”

Still, it is unclear whether TikTok poses a unique and specific threat to US national security or if it is simply a convenient proxy through which lawmakers are grappling with larger issues of data security and privacy, disinformation, content moderation, and influence in a globalized tech market. Similarly, the Chinese telecom giant Huawei faced controversy over whether the US should incorporate Chinese-made hardware into domestic 5G infrastructure, which was ultimately banned.

“There are definitely signs that Chinese influence efforts are likely to grow, linked to the Chinese government’s strategy more broadly of digital authoritarianism,” says Kian Vesteinsson, a research analyst for the nonprofit digital rights think tank Freedom House. “But it’s important for us to acknowledge that the US government has its own shadowy national security surveillance authorities. And in recent years, US government agencies have monitored social media accounts of people coordinating protests in the US and done things like searched electronic devices throughout the country and at the border. These sorts of tactics undermine the idea that this is only a foreign threat.”

Then there's the power imbalance TikTok may create. One thing about TikTok, in particular, is that its popularity and proliferation within the US could make it a one-stop shop for the Chinese government to mine the data of US users and launch influence operations in the US. Meanwhile, the US government may feel that it lacks a comparable mechanism through which it can so directly pull Chinese user data and work to sway public opinion in China.

“Let's assume for a second that US intelligence has access to WeChat. They would have to fight hard for that access, and it would constantly be at risk of discovery and neutralization. China, on the other hand, doesn't have to fight for access to TikTok; they have it by statutory authority,” says Jake Williams, director of cyber-threat intelligence at the security firm Scythe and a former National Security Agency hacker. “By itself, I don't think that the TikTok app on people's devices is a significant threat, but the potential for Chinese data collection across the platform is a larger concern, especially when combined with other data already acquired by Chinese state actors.”

Given its immense popularity, its ownership, and the fact that the bulk of TikTok activity is public by nature, there is no clear technical solution to boxing China out of the service. The question is whether the US government wants to devise a business solution or incentivize development of an appealing alternative platform. Still, privacy violations, security concerns, and foreign influence operations against US residents through social media are problems the US government has yet to solve. And neither technology bans nor countersurveillance will make them go away.

“One thing that we really should escalate here is that the US should be leading by example,” Freedom House's Vesteinsson says. “When we talk about expanding the US government’s surveillance powers, that sets a really bad example for governments around the world.”

It’s Time to Get Real About TikTok’s Risks

OpenSSF welcomes Capital One as a premier member affirming its commitment to strengthening the open source software supply chain.

**SAN FRANCISCO, Aug. 24, 2022** — Capital One joins the Open Source Security Foundation (OpenSSF) as a premier member, affirming its commitment to strengthening the open source software supply chain. OpenSSF is a cross-industry organization hosted at the Linux Foundation, designed to inspire and enable the community to secure the open source software we all depend on, including development, testing, fundraising, infrastructure, and support initiatives.

Capital One joins the OpenSSF Governing Board in charge of leading the organization and providing strategic direction. “We are happy to welcome Capital One to the Open Source Security Foundation,” says Brian Behlendorf, General Manager of OpenSSF. “As a highly regulated company that has invested in technology, Capital One has experience building the governance structure, modern architecture and collaborative culture that is critical for well-managed open source software delivery. By joining the OpenSSF, Capital One is demonstrating a serious commitment to secure open source software that benefits our entire ecosystem.”

As one of the nation’s leading digital banks, technology is central to Capital One’s business strategy and how value is delivered to more than 100 million customers. The company began a technology transformation over a decade ago, which included an open source-first declaration in 2015. A modern architecture in the cloud is allowing Capital One to take advantage of the world’s innovations and accelerate delivery by committing to a collaborative software-building approach among the open source community.

“Today some of the most ground-breaking digital experiences created for customers are based on open source software. As a company that widely adopts this technology, Capital One is incredibly proud to join the OpenSSF and the world’s technology leaders as we collaborate to strengthen the software security supply chain,” said Chris Nims, EVP of Cloud & Productivity Engineering at Capital One. “As a highly-regulated company, we are seasoned in managing compliance and governance and advocate for standardization, automation and collaboration. We look forward to working together to identify solutions that advance the OpenOSSF mission and give back to the open source community.”

Earlier this year, the OpenSSF unveiled a 10-point plan at the Open Source Security Summit hosted in conjunction with the White House in May. The plan feeds into 10 different workstreams, like finding ways to reduce patching response times for open source software, developing new metrics to track code and components, moving the industry away from non-memory safe programming languages that make it difficult to find and fix vulnerabilities, establishing a framework for incident response teams that can be deployed across the open source community and conducting annual third-party reviews of the top 200 most critical open source security components.

More recently, the OpenSSF hosted a Town Hall especially for open source software maintainers, contributors, software developers, and open source software users who know security is important, but haven’t made the leap to join an OpenSSF Working Group or Project yet. On Tuesday, Sept. 13, they will be hosting an OpenSSF Day EU at the Open Source Summit Europe in Dublin, Ireland, and online.

Capital One joins other OpenSSF premier members 1Password, AWS, Atlassian, Cisco, Citi, Coinbase, Dell Technologies, Ericsson, Fidelity, GitHub, Google, Huawei, Intel, IBM, JFrog, JPMorgan Chase, Meta, Microsoft, Morgan Stanley, Oracle, Red Hat, Snyk, Sonatype, VMware, and Wipro.

**About OpenSSF**

The Open Source Security Foundation (OpenSSF) is a cross-industry organization hosted by the Linux Foundation that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. The OpenSSF is committed to collaboration and working both upstream and with existing communities to advance open source security for all. For more information, please visit us at: openssf.org.

**About the Linux Foundation**

Founded in 2000, the Linux Foundation and its projects are supported by more than 2,950 members. The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, ONAP, Hyperledger, RISC-V, and more. The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

Capital One Joins Open Source Security Foundation

** UNSUPPORTED WHEN ASSIGNED ** An issue in the UPnP protocol in 4thline cling 2.0.0 through 2.1.2 allows remote attackers to cause a denial of service via an unchecked CALLBACK parameter in the request header.

Universal Plug and Play (UPnP), a ubiquitous protocol used by “billions of devices,” may be vulnerable to data exfiltration and reflected amplified TCP distributed denial of service (DDoS) attacks.

**Background**

On June 8, researcher Yunus Çadirci published an advisory for CallStranger, a vulnerability in the Universal Plug and Play (UPnP) protocol. UPnP is currently managed by the Open Connectivity Foundation (OCF). As its name implies, UPnP is a protocol designed to allow a variety of networked devices to universally communicate with each other without any special setup or configuration.

Because of its ubiquitous nature, UPnP is used by a wide variety of devices, including personal computers, networking equipment, video game consoles and internet of things (IoT) devices such as smart televisions. As a result, Çadirci says this particular vulnerability potentially affects “billions of devices.”

**Analysis**

CVE-2020-12695 is a server-side request forgery (SSRF)-like vulnerability in devices that utilize UPnP. The vulnerability exists due to the ability to control the Callback header value in the UPnP SUBSCRIBE function.

Source: CallStranger Technical Report

The SUBSCRIBE function is part of the UPnP standard that allows devices to monitor changes in other devices and services. For example, the PoC published on GitHub shows port 2869 for Microsoft’s Xbox One — which is used to monitor device changes on the network for features like media sharing — as vulnerable.

In order to exploit the flaw, an attacker would need to send a specially crafted HTTP SUBSCRIBE request to a vulnerable device.

An attacker could utilize this vulnerability in the following scenarios:

*   Intranet device port scanning to gather additional data from trusted assets within an organization’s LAN, bypassing organizational Data Loss Prevention (DLP) standards.
*   Send large amounts of traffic to arbitrary destinations. Targets flooded by the affected devices could crash under the increased network load, resulting in a denial of service (DoS). This is a result of UPnP attempting to establish a TCP handshake with multiple SYN packets for all Callback values in the SUBSCRIBE request.
*   Exfiltrate sensitive device data by directing callback information to arbitrary targets.

With the exception of the DoS, these scenarios provide a stealthy method for an attacker to steal data from a compromised network. This sensitive information could potentially open up an organization to further attack.

**Proof of concept**

The original proof of concept (PoC) created by Çadirci has been added to his GitHub repository.

**Solution**

Since CallStranger is a protocol-level vulnerability, OCF has made changes to the UPnP protocol specification. Therefore, manufacturers of affected devices are in the process of determining its impact. As a result, we anticipate newly affected devices will be reported and patches will be released over time for devices still receiving product support. Tenable product coverage for this vulnerability can be found in the “identifying affected systems” section below.

At the time this blog post was published, the CallStranger website listed the following operating systems, networking equipment, printers, IoT devices and applications as reportedly vulnerable.

****Operating Systems****

**Vendor/Model**

**Version**

Windows 10

10.0.18362.719

Xbox One OS

10.0.19041.2494

****Networking Equipment****

**Vendor/Model**

**Version**

ASUS

RT-N11

Broadcom ADSL

\-

Cisco Wireless Access Point

WAP150 WAP131 WAP351

D-Link

DVG-N5412SP

Huawei

HG255s (HG255sC163B03) HG532e MyBox

NEC AccessTechnica

WR8165N

Netgear

WNHDE111

Ruckus ZoneDirector

\-

TP-Link

Archer C50

ZTE

ZXV10 W300 H108N

Zyxel

AMG1202-T10B

****Printers****

**Vendor/Model**

**Version**

Canon Selphy

CP1200

Dell

B1165NFW

EPSON EP, EW, XP Series Printers

\-

Hewlett Packard Deskjet, Photsmart and Officejet ENVY

\-

Samsung

X4300

****Internet of Things****

**Vendor/Model**

**Version**

Canal Digital ADB

TNR-5720 SX

Belkin Wemo

\-

Nokia HomeMusic Media Device

\-

Panasonic

BB-HCM735 VL-MWN350

Philips

2k14MTK TV (TPL161E\_012.003.039.001)

Samsung

UE55MU7000 (T-KTMDEUC-1280.5, BT - S) MU8000

Siemens

CNE1000

Trendnet

TV-IP551W

****Applications****

**Vendor/Model**

**Version**

ASUS Media Streamer

\-

LG Smartshare Media

\-

Sony Media Go Media

\-

Stream What You Hear

\-

Ubiquiti UniFi Controller

\-

**Identifying affected systems**

A list of Tenable plugins to identify this vulnerability will appear here as they’re released. Additionally, the table below lists several Tenable plugins to help identify devices within your network that may have UPnP enabled.

**Plugin ID**

**Description**

**Product**

10829

UPnP Client Detection

Nessus

35711

Universal Plug and Play (UPnP) Protocol Detection

Nessus

8061

UPNP Traffic Detection (Client)

Nessus Network Monitor (NMM)

1948

UPNP Traffic Detection

Nessus Network Monitor (NMM)

**Get more information**

*   CallStranger Disclosure Site
*   CERT/CC CallStranger Advisory (VU#339275)
*   Proof of Concept Code released on GitHub

**_Join Tenable's Security Response Team on the Tenable Community._**

**_Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface._**

Get a free 30-day trial of Tenable.io Vulnerability Management.

CVE-2020-23622: CVE-2020-12695: CallStranger Vulnerability in Universal Plug and Play (UPnP) Puts Billions of Devices At Risk

The My HUAWEI app has a defect in the design. Successful exploitation of this vulnerability may affect data confidentiality.

CVE-2021-40030

Vulnerability of writing data to an arbitrary address in the HW_KEYMASTER module. Successful exploitation of this vulnerability may affect confidentiality.

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 July 2022 Android security bulletin:

Critical: CVE-2022-20222, CVE-2022-20229

High: CVE-2022-20221, CVE-2022-20223, CVE-2022-20224, CVE-2022-20225, CVE-2022-20226, CVE-2022-20228, CVE-2022-20230, CVE-2022-20220, CVE-2022-20227, CVE-2022-22058

Medium: none

Low: none

Already included in previous updates: CVE-2022-20124, CVE-2022-20129, CVE-2022-20138, CVE-2022-20144, CVE-2022-20194, CVE-2022-20198, CVE-2022-20209, CVE-2018-25020, CVE-2021-44733, CVE-2021-33034, CVE-2022-20154, CVE-2021-35073, CVE-2021-35076, CVE-2021-35086, CVE-2021-35096, CVE-2021-30340, CVE-2021-30343, CVE-2021-30347, CVE-2022-20123, CVE-2022-20127, CVE-2022-20131, CVE-2022-20147, CVE-2022-21745

※ 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-40040: Vulnerability of writing data to an arbitrary address in the HW\_KEYMASTER module

Severity: Critical

Affected versions: 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 affect confidentiality.

CVE-2021-40034: Memory overwriting vulnerability caused by addition overflow in the video framework

Severity: Critical

Affected versions: 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 can affect availability.

CVE-2021-40030: Vulnerability of defects being introduced in the design process in the My HUAWEI app

Severity: Medium

Affected versions: 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 will affect confidentiality.

CVE-2021-40012: Vulnerability of pointers being incorrectly used during data transmission in the video framework

Severity: Medium

Affected versions: EMUI 11.0.0, Magic UI 4.0.0

Impact: Successful exploitation of this vulnerability may affect confidentiality.

CVE-2022-37004: OOBE bypass vulnerability in Settings

Severity: High

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 affect service availability.

CVE-2022-37005: Argument injection vulnerability in Settings

Severity: Medium

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

Impact: Successful exploitation of this vulnerability may affect confidentiality.

CVE-2021-46741: Vulnerability of defects being introduced in the design process in the basic framework and settings module

Severity: Medium

Affected versions: 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 will affect integrity.

CVE-2022-37007: Out-of-bounds read vulnerability in the ChinaDRM module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.0, Magic UI 4.0.0

Impact: Successful exploitation of this vulnerability may affect service availability.

CVE-2022-37008: Vulnerability of the update package not being verified before used in the recovery module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1, EMUI 11.0.0, Magic UI 4.0.0

Impact: Successful exploitation of this vulnerability will affect system stability.

CVE-2022-37002: Unauthorized access vulnerability in the SystemUI module

Severity: High

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 can cause malicious applications to run or display pop-ups in the background.

CVE-2022-34742: Read/Write vulnerability in system components

Severity: High

Affected versions: EMUI 11.0.1

Impact: Successful exploitation of this vulnerability will affect confidentiality.

CVE-2022-37003: Incorrect permission assignment vulnerability in the AOD lock screen module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.0, Magic UI 4.0.0

Impact: Successful exploitation of this vulnerability will cause files in the directory to be read and written, resulting in privilege escalation.

CVE-2022-37006: Permission control vulnerability in the network module

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may affect service availability.

CVE-2021-40040: August

In Task.java, there is a possible escalation of privilege due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12Android ID: A-185810717

_Published August 1, 2022 | Updated August 3, 2022_

The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2022-08-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 have been released to the Android Open Source Project (AOSP) repository and linked from this bulletin. This bulletin also includes links to patches outside of AOSP.

The most severe of these issues is a critical security vulnerability in the System component that could lead to remote code execution over Bluetooth with no additional 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-08-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-08-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 no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2021-39696

A-185810717

EoP

High

10, 11, 12

CVE-2022-20344

A-232541124

EoP

High

10, 11, 12, 12L

CVE-2022-20348

A-228315529

EoP

High

10, 11, 12, 12L

CVE-2022-20349

A-228315522

EoP

High

10, 11, 12, 12L

CVE-2022-20356

A-215003903

EoP

High

11, 12, 12L

CVE-2022-20350

A-228178437 \[2\]

ID

High

10, 11, 12, 12L

CVE-2022-20352

A-222473855

ID

High

12, 12L

CVE-2022-20357

A-214999987

ID

High

12, 12L

CVE-2022-20358

A-203229608

ID

High

10, 11, 12, 12L

**Media Framework**

The most severe vulnerability in this section could lead to remote information disclosure with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20346

A-230493653

ID

High

10, 11, 12, 12L

CVE-2022-20353

A-221041256 \[2\] \[3\]

ID

High

10, 11, 12, 12L

**System**

The most severe vulnerability in this section could lead to remote code execution over Bluetooth with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20345

A-230494481

RCE

Critical

12, 12L

CVE-2022-20347

A-228450811

EoP

High

10, 11, 12, 12L

CVE-2022-20354

A-219546241

EoP

High

11, 12, 12L

CVE-2022-20360

A-228314987

EoP

High

10, 11, 12, 12L

CVE-2022-20361

A-231161832

EoP

High

10, 11, 12, 12L

CVE-2022-20355

A-219498290 \[2\]

DoS

High

10, 11, 12, 12L

**Google Play system updates**

The following issues are included in Project Mainline components.

 

Component

CVE

Media Framework components

CVE-2022-20346

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

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-08-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 vulnerability in this section could lead to local escalation of privileges with User execution privileges needed.

    

CVE

References

Type

Severity

Component

CVE-2022-1786

A-233078742  
Upstream kernel

EoP

High

Filesystem (fs)

**Imagination Technologies**

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

   

CVE

References

Severity

Component

CVE-2021-0698  

A-236848165\*

High

PowerVR-GPU

CVE-2021-0887  

A-236848817\*

High

PowerVR-GPU

CVE-2021-0891

A-236849490\*

High

PowerVR-GPU

CVE-2021-0946  

A-236846966\*

High

PowerVR-GPU

CVE-2021-0947  

A-236838960\*

High

PowerVR-GPU

CVE-2021-39815

A-232440670\*

High

PowerVR-GPU

CVE-2022-20122

A-232441339\*

High

PowerVR-GPU

**MediaTek components**

This vulnerability affects MediaTek components and further details are available directly from MediaTek. The severity assessment of this issue is provided directly by MediaTek.

   

CVE

References

Severity

Component

CVE-2022-20082

A-231271467  
M-ALPS07044730\*

High

GPU

**Unisoc components**

This vulnerability affects Unisoc components and further details are available directly from Unisoc. The severity assessment of this issue is provided directly by Unisoc.

   

CVE

References

Severity

Component

CVE-2022-20239

A-233972091  
U-1883877\*

High

VSP

**Qualcomm components**

This vulnerability affects Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of this issue is provided directly by Qualcomm.

   

CVE

References

Severity

Component

CVE-2022-22080  

A-231156274  
QC-CR#2898981

High

Audio

**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-30259

A-187074564\*

High

Closed-source component

CVE-2022-22059

A-231156126\*

High

Closed-source component

CVE-2022-22061

A-218338332\*

High

Closed-source component

CVE-2022-22062  

A-218338070\*

High

Closed-source component

CVE-2022-22067

A-218338889\*

High

Closed-source component

CVE-2022-22069

A-218339148\*

High

Closed-source component

CVE-2022-22070

A-218338870\*

High

Closed-source component

CVE-2022-25668

A-231156523\*

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-08-01 or later address all issues associated with the 2022-08-01 security patch level.
*   Security patch levels of 2022-08-05 or later address all issues associated with the 2022-08-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-08-01\]
*   \[ro.build.version.security\_patch\]:\[2022-08-05\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2022-08-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-08-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-08-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 mvalue 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

August 1, 2022

Bulletin Published

1.1

August 3, 2022

Bulletin revised to include AOSP links

CVE-2021-39696: Android Security Bulletin—August 2022  |  Android Open Source Project

A security researcher found an open database belonging to JusTalk, a China-based video call and messaging app company.
The post For months, JusTalk messages were accessible to everyone on the Internet appeared first on Malwarebytes Labs.

Posted: August 3, 2022 by

JusTalk, a popular mobile video calling and messaging app with 20 million global users, exposed a massive database of supposedly private messages to the public Internet for months. According to security researcher Anurag Sen, who discovered the open database, the messages were stored unencrypted, and the database itself was not locked behind a password.

“Rest assured your calls and messages are secured,” the JusTalk website reads, “Only you and the person you communicate with can see, read, or listen to them: even the JusTalk team won’t access your data!”

The JusTalk website assures users their messages are secured

But, as we know, “won’t access” is not the same as “can’t access”. And when anybody has the ability to see somebody else’s private data, it opens the door for both malice and mistakes.

The open database is a logging database the company, Ningbo Jus Internet Technology, uses to keep track of app bugs and errors. It also houses hundreds of gigabytes of data and is hosted on a Huawei cloud server in China. Sen said anyone can access the data using a web browser if they have the right IP address.

Data collected from Shodan, a search engine for exposed devices and databases, shows that the company continued to use the database until it was first exposed in early January (at least).

Because the database is, essentially, a smorgasbord of every data the company collects—chat logs, video logs, granular location data, data of child users of their JusTalk Kids app, records from their JusTalk second phone number—it’s complicated to put a number on affected victims of this breach. However, it is prudent to assume everyone using Ningbo Jus’s products is affected.

> The server was collecting and storing more than 10 million individual logs each day, including millions of messages sent over the app, including the phone numbers of the sender, the recipient and the message itself. The database also logged all placed calls, which included the caller’s and recipient’s phone numbers in each record.
> 
> ~ Zack Whittaker, TechCrunch

Shortly after TechCrunch published a story on JusTalk not really having end-to-end encryption, the open database was no longer accessible.

As Shodan is used by security researchers and online criminals alike, TechCrunch found evidence that someone had already accessed the database—perhaps even created copies of the data there. The outlet found an undated ransom note left by a data extortionist in the database for the company to find.

Because the database has all collected data stored in one place, it’s doubtful that the company even noticed this ransom note. Ningbo Jus may not even know that it’s already being extorted.

The blockchain address associated with the ransom note has not yet received any funds.

**RELATED ARTICLES**

For months, JusTalk messages were accessible to everyone on the Internet

Categories: Privacy
Tags: data breach

Tags: shodan

Tags: TechCrunch

A security researcher found an open database belonging to JusTalk, a China-based video call and messaging app company.



(Read more...)




The post For months, JusTalk messages were accessible to everyone on the Internet appeared first on Malwarebytes Labs.

Posted: August 3, 2022 by

JusTalk, a popular mobile video calling and messaging app with 20 million global users, exposed a massive database of supposedly private messages to the public Internet for months. According to security researcher Anurag Sen, who discovered the open database, the messages were stored unencrypted, and the database itself was not locked behind a password.

"Rest assured your calls and messages are secured," the JusTalk website reads, "Only you and the person you communicate with can see, read, or listen to them: even the JusTalk team won't access your data!"

The JusTalk website assures users their messages are secured

But, as we know, "won't access" is not the same as "can't access". And when anybody has the ability to see somebody else's private data, it opens the door for both malice and mistakes.

The open database is a logging database the company, Ningbo Jus Internet Technology, uses to keep track of app bugs and errors. It also houses hundreds of gigabytes of data and is hosted on a Huawei cloud server in China. Sen said anyone can access the data using a web browser if they have the right IP address.

Data collected from Shodan, a search engine for exposed devices and databases, shows that the company continued to use the database until it was first exposed in early January (at least).

Because the database is, essentially, a smorgasbord of every data the company collects—chat logs, video logs, granular location data, data of child users of their JusTalk Kids app, records from their JusTalk second phone number—it's complicated to put a number on affected victims of this breach. However, it is prudent to assume everyone using Ningbo Jus's products is affected.

> The server was collecting and storing more than 10 million individual logs each day, including millions of messages sent over the app, including the phone numbers of the sender, the recipient and the message itself. The database also logged all placed calls, which included the caller’s and recipient’s phone numbers in each record.
> 
> ~ Zack Whittaker, TechCrunch

Shortly after TechCrunch published a story on JusTalk not really having end-to-end encryption, the open database was no longer accessible.

As Shodan is used by security researchers and online criminals alike, TechCrunch found evidence that someone had already accessed the database—perhaps even created copies of the data there. The outlet found an undated ransom note left by a data extortionist in the database for the company to find.

Because the database has all collected data stored in one place, it's doubtful that the company even noticed this ransom note. Ningbo Jus may not even know that it's already being extorted.

The blockchain address associated with the ransom note has not yet received any funds.

**RELATED ARTICLES**

A race condition in the Linux kernel before 5.5.7 involving VT_RESIZEX could lead to a NULL pointer dereference and general protection fault.

CVE-2020-36558

When setting font with malicous data by ioctl cmd PIO_FONT,kernel will write memory out of bounds.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307

    From ff2047fb755d4415ec3c70ac799889371151796d Mon Sep 17 00:00:00 2001
    From: Jiri Slaby <jslaby@suse.cz>
    Date: Tue, 5 Jan 2021 13:02:35 +0100
    Subject: vt: drop old FONT ioctls
    
    From: Jiri Slaby <jslaby@suse.cz>
    
    commit ff2047fb755d4415ec3c70ac799889371151796d upstream.
    
    Drop support for these ioctls:
    * PIO_FONT, PIO_FONTX
    * GIO_FONT, GIO_FONTX
    * PIO_FONTRESET
    
    As was demonstrated by commit 90bfdeef83f1 (tty: make FONTX ioctl use
    the tty pointer they were actually passed), these ioctls are not used
    from userspace, as:
    1) they used to be broken (set up font on current console, not the open
       one) and racy (before the commit above)
    2) KDFONTOP ioctl is used for years instead
    
    Note that PIO_FONTRESET is defunct on most systems as VGA_CONSOLE is set
    on them for ages. That turns on BROKEN_GRAPHICS_PROGRAMS which makes
    PIO_FONTRESET just return an error.
    
    We are removing KD_FONT_FLAG_OLD here as it was used only by these
    removed ioctls. kd.h header exists both in kernel and uapi headers, so
    we can remove the kernel one completely. Everyone includeing kd.h will
    now automatically get the uapi one.
    
    There are now unused definitions of the ioctl numbers and "struct
    consolefontdesc" in kd.h, but as it is a uapi header, I am not touching
    these.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Link: https://lore.kernel.org/r/20210105120239.28031-8-jslaby@suse.cz
    Cc: guodaxing <guodaxing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    ---
     drivers/tty/vt/vt.c       |   39 -----------
     drivers/tty/vt/vt_ioctl.c |  151 ----------------------------------------------
     include/linux/kd.h        |    8 --
     3 files changed, 3 insertions(+), 195 deletions(-)
     delete mode 100644 include/linux/kd.h
    
    --- a/drivers/tty/vt/vt.c
    +++ b/drivers/tty/vt/vt.c
    @@ -4625,16 +4625,8 @@ static int con_font_get(struct vc_data *
     
     	if (op->data && font.charcount > op->charcount)
     		rc = -ENOSPC;
    -	if (!(op->flags & KD_FONT_FLAG_OLD)) {
    -		if (font.width > op->width || font.height > op->height) 
    -			rc = -ENOSPC;
    -	} else {
    -		if (font.width != 8)
    -			rc = -EIO;
    -		else if ((op->height && font.height > op->height) ||
    -			 font.height > 32)
    -			rc = -ENOSPC;
    -	}
    +	if (font.width > op->width || font.height > op->height)
    +		rc = -ENOSPC;
     	if (rc)
     		goto out;
     
    @@ -4662,7 +4654,7 @@ static int con_font_set(struct vc_data *
     		return -EINVAL;
     	if (op->charcount > 512)
     		return -EINVAL;
    -	if (op->width <= 0 || op->width > 32 || op->height > 32)
    +	if (op->width <= 0 || op->width > 32 || !op->height || op->height > 32)
     		return -EINVAL;
     	size = (op->width+7)/8 * 32 * op->charcount;
     	if (size > max_font_size)
    @@ -4672,31 +4664,6 @@ static int con_font_set(struct vc_data *
     	if (IS_ERR(font.data))
     		return PTR_ERR(font.data);
     
    -	if (!op->height) {		/* Need to guess font height [compat] */
    -		int h, i;
    -		u8 *charmap = font.data;
    -
    -		/*
    -		 * If from KDFONTOP ioctl, don't allow things which can be done
    -		 * in userland,so that we can get rid of this soon
    -		 */
    -		if (!(op->flags & KD_FONT_FLAG_OLD)) {
    -			kfree(font.data);
    -			return -EINVAL;
    -		}
    -
    -		for (h = 32; h > 0; h--)
    -			for (i = 0; i < op->charcount; i++)
    -				if (charmap[32*i+h-1])
    -					goto nonzero;
    -
    -		kfree(font.data);
    -		return -EINVAL;
    -
    -	nonzero:
    -		op->height = h;
    -	}
    -
     	font.charcount = op->charcount;
     	font.width = op->width;
     	font.height = op->height;
    --- a/drivers/tty/vt/vt_ioctl.c
    +++ b/drivers/tty/vt/vt_ioctl.c
    @@ -486,70 +486,6 @@ static int vt_k_ioctl(struct tty_struct
     	return 0;
     }
     
    -static inline int do_fontx_ioctl(struct vc_data *vc, int cmd,
    -		struct consolefontdesc __user *user_cfd,
    -		struct console_font_op *op)
    -{
    -	struct consolefontdesc cfdarg;
    -	int i;
    -
    -	if (copy_from_user(&cfdarg, user_cfd, sizeof(struct consolefontdesc)))
    -		return -EFAULT;
    -
    -	switch (cmd) {
    -	case PIO_FONTX:
    -		op->op = KD_FONT_OP_SET;
    -		op->flags = KD_FONT_FLAG_OLD;
    -		op->width = 8;
    -		op->height = cfdarg.charheight;
    -		op->charcount = cfdarg.charcount;
    -		op->data = cfdarg.chardata;
    -		return con_font_op(vc, op);
    -
    -	case GIO_FONTX:
    -		op->op = KD_FONT_OP_GET;
    -		op->flags = KD_FONT_FLAG_OLD;
    -		op->width = 8;
    -		op->height = cfdarg.charheight;
    -		op->charcount = cfdarg.charcount;
    -		op->data = cfdarg.chardata;
    -		i = con_font_op(vc, op);
    -		if (i)
    -			return i;
    -		cfdarg.charheight = op->height;
    -		cfdarg.charcount = op->charcount;
    -		if (copy_to_user(user_cfd, &cfdarg, sizeof(struct consolefontdesc)))
    -			return -EFAULT;
    -		return 0;
    -	}
    -	return -EINVAL;
    -}
    -
    -static int vt_io_fontreset(struct vc_data *vc, struct console_font_op *op)
    -{
    -	int ret;
    -
    -	if (__is_defined(BROKEN_GRAPHICS_PROGRAMS)) {
    -		/*
    -		 * With BROKEN_GRAPHICS_PROGRAMS defined, the default font is
    -		 * not saved.
    -		 */
    -		return -ENOSYS;
    -	}
    -
    -	op->op = KD_FONT_OP_SET_DEFAULT;
    -	op->data = NULL;
    -	ret = con_font_op(vc, op);
    -	if (ret)
    -		return ret;
    -
    -	console_lock();
    -	con_set_default_unimap(vc);
    -	console_unlock();
    -
    -	return 0;
    -}
    -
     static inline int do_unimap_ioctl(int cmd, struct unimapdesc __user *user_ud,
     		bool perm, struct vc_data *vc)
     {
    @@ -574,29 +510,7 @@ static inline int do_unimap_ioctl(int cm
     static int vt_io_ioctl(struct vc_data *vc, unsigned int cmd, void __user *up,
     		bool perm)
     {
    -	struct console_font_op op;	/* used in multiple places here */
    -
     	switch (cmd) {
    -	case PIO_FONT:
    -		if (!perm)
    -			return -EPERM;
    -		op.op = KD_FONT_OP_SET;
    -		op.flags = KD_FONT_FLAG_OLD | KD_FONT_FLAG_DONT_RECALC;	/* Compatibility */
    -		op.width = 8;
    -		op.height = 0;
    -		op.charcount = 256;
    -		op.data = up;
    -		return con_font_op(vc, &op);
    -
    -	case GIO_FONT:
    -		op.op = KD_FONT_OP_GET;
    -		op.flags = KD_FONT_FLAG_OLD;
    -		op.width = 8;
    -		op.height = 32;
    -		op.charcount = 256;
    -		op.data = up;
    -		return con_font_op(vc, &op);
    -
     	case PIO_CMAP:
                     if (!perm)
     			return -EPERM;
    @@ -605,20 +519,6 @@ static int vt_io_ioctl(struct vc_data *v
     	case GIO_CMAP:
                     return con_get_cmap(up);
     
    -	case PIO_FONTX:
    -		if (!perm)
    -			return -EPERM;
    -
    -		fallthrough;
    -	case GIO_FONTX:
    -		return do_fontx_ioctl(vc, cmd, up, &op);
    -
    -	case PIO_FONTRESET:
    -		if (!perm)
    -			return -EPERM;
    -
    -		return vt_io_fontreset(vc, &op);
    -
     	case PIO_SCRNMAP:
     		if (!perm)
     			return -EPERM;
    @@ -1099,54 +999,6 @@ void vc_SAK(struct work_struct *work)
     
     #ifdef CONFIG_COMPAT
     
    -struct compat_consolefontdesc {
    -	unsigned short charcount;       /* characters in font (256 or 512) */
    -	unsigned short charheight;      /* scan lines per character (1-32) */
    -	compat_caddr_t chardata;	/* font data in expanded form */
    -};
    -
    -static inline int
    -compat_fontx_ioctl(struct vc_data *vc, int cmd,
    -		   struct compat_consolefontdesc __user *user_cfd,
    -		   int perm, struct console_font_op *op)
    -{
    -	struct compat_consolefontdesc cfdarg;
    -	int i;
    -
    -	if (copy_from_user(&cfdarg, user_cfd, sizeof(struct compat_consolefontdesc)))
    -		return -EFAULT;
    -
    -	switch (cmd) {
    -	case PIO_FONTX:
    -		if (!perm)
    -			return -EPERM;
    -		op->op = KD_FONT_OP_SET;
    -		op->flags = KD_FONT_FLAG_OLD;
    -		op->width = 8;
    -		op->height = cfdarg.charheight;
    -		op->charcount = cfdarg.charcount;
    -		op->data = compat_ptr(cfdarg.chardata);
    -		return con_font_op(vc, op);
    -
    -	case GIO_FONTX:
    -		op->op = KD_FONT_OP_GET;
    -		op->flags = KD_FONT_FLAG_OLD;
    -		op->width = 8;
    -		op->height = cfdarg.charheight;
    -		op->charcount = cfdarg.charcount;
    -		op->data = compat_ptr(cfdarg.chardata);
    -		i = con_font_op(vc, op);
    -		if (i)
    -			return i;
    -		cfdarg.charheight = op->height;
    -		cfdarg.charcount = op->charcount;
    -		if (copy_to_user(user_cfd, &cfdarg, sizeof(struct compat_consolefontdesc)))
    -			return -EFAULT;
    -		return 0;
    -	}
    -	return -EINVAL;
    -}
    -
     struct compat_console_font_op {
     	compat_uint_t op;        /* operation code KD_FONT_OP_* */
     	compat_uint_t flags;     /* KD_FONT_FLAG_* */
    @@ -1223,9 +1075,6 @@ long vt_compat_ioctl(struct tty_struct *
     	/*
     	 * these need special handlers for incompatible data structures
     	 */
    -	case PIO_FONTX:
    -	case GIO_FONTX:
    -		return compat_fontx_ioctl(vc, cmd, up, perm, &op);
     
     	case KDFONTOP:
     		return compat_kdfontop_ioctl(up, perm, &op, vc);
    --- a/include/linux/kd.h
    +++ /dev/null
    @@ -1,8 +0,0 @@
    -/* SPDX-License-Identifier: GPL-2.0 */
    -#ifndef _LINUX_KD_H
    -#define _LINUX_KD_H
    -
    -#include <uapi/linux/kd.h>
    -
    -#define KD_FONT_FLAG_OLD		0x80000000	/* Invoked via old interface [compat] */
    -#endif /* _LINUX_KD_H */

Tag

#huawei