Chrome's Stable Channel 107 rollout includes security fixes from a slew of independent researchers, racking up nearly $60,000 in bounties.

Google Chrome's rollout of its latest browser update includes 14 individual security fixes — three high-severity — found by independent researchers who earned bug bounty payouts totaling more than $57,000. 

There is still one high-severity bug with a payout amount listed as "TBD," meaning the final collective tally could top $60,000. 

The latest update, Chrome 107 for Windows, Mac, and Linux, will roll out over the coming days, Google announced, along with the new version's security improvements. 

"We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel," the Chrome team said about the update's release. 

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Google Chrome Pays $57K (and Counting) in Bug Bounties for Latest Update

The manufacturing segment was especially hard hit by cyberattacks in the third quarter of 2022.

Ransomware gangs are hitting the industrial sector hard — and especially manufacturing companies, with significant spikes in cyberattack activity against US organizations spotted in the third quarter. Meanwhile, emerging ransomware groups are bursting onto the scene, threatening to push the rate of attacks up even higher.

According to a Dragos Q3 analysis of ransomware attacks on industrial organizations, 36% of the recorded cases globally hit North America (46 incidents). This is a significant 10% increase over last quarter, when a quarter of cases affected the region.

However, the analysis also found that the rate of attacks globally remained flat quarter over quarter — 128 incidents for Q3 vs. 125 in Q2.

The majority (68%) of observed incidents were aimed at the manufacturing sector. Out of the confirmed attacks (i.e., those publicly reported, seen in the firm's telemetry, or confirmed on the Dark Web), 88 were against that segment, especially those producing metal products (12 attacks).

Stephen Banda, senior manager of security solutions at Lookout, noted that the manufacturing sector, like everyone else, is moving to the cloud; digitizing manufacturing, inventory tracking, operations, and maintenance increases agility and efficiency, with less production downtime and a greater nimbleness. But it also opens up new attack surfaces.

"To remain competitive, manufacturers are investing in intellectual property and new technologies like digital twins," he tells Dark Reading. "In short, manufacturers are transforming the way they produce and deliver goods - moving toward industrial automation and the flexible factory. This transformation, known as Industry 4.0, puts pressure on mobile devices and cloud solutions."

Yet for most manufacturers, security solutions still remain on-premises, he adds.

"This creates efficacy and scalability challenges when tasked with protecting productivity solutions that have moved to the cloud," he notes. "Security therefore must also move to the cloud to adequately safeguard manufacturing operations."

As for other industrial segments, 9% of attacks targeted the food and beverage sector (12 incidents), followed by oil and natural gas (6%, or eight incidents) and the energy and pharmaceuticals sectors (collectively making up 10% of attacks, with seven and six incidents respectively). The chemical, mining, engineering, and water and wastewater systems segments had just one attack each.  

**Different Threat Actors Target Different Industrial Segments**

In terms of the actors on the industrial stage, the LockBit gang was behind more than a third of all global incidents (35%), while some other known names focused on the energy sector (Ragnar Locker and BlackCat/AlphaV, notably). But the quarter also saw the rise of some emerging actors, like Sparta Blog, BianLian, Donuts, Onyx, and the slow-burning Yanluowang.

In all cases, various groups seemed to have specialties, Dragos noted, including:

*   Ragnar Locker has been targeting mainly energy.
*   Cl0p Leaks has been targeting only water and wastewater.
*   Karakurt has targeted only manufacturing in Q3, while in Q2, it only targeted transportation entities.
*   LockBit 3.0 is the only group that targeted chemicals, drilling, industrial supplies, and interior design.
*   Stormous has only targeted Vietnam.
*   Lorenz has only targeted the United States.
*   Sparta Blog has only targeted Spain.
*   Black Basta and Hive mainly targeted the transportation sector.

Bud Broomhead, CEO at Viakoo, noted that specific ransomware strains targeting specific industries should galvanize intelligence sharing.

"This should spur more industry-level coordination to protect against those threats, specifically between companies that otherwise would compete in the marketplace," he says. "Rather than every organization individually mounting defenses, industry-wide responses are needed (put another way, cybercriminals are attacking an industry which requires industry-level responses). Threat actors don’t exist in silos, so why should the response to them be siloed?"

That coordination could be vitally important, given that going forward, Dragos researchers warned that more new ransomware groups will appear in the next quarter, as either new or reformed ones, due to the changes in ransomware groups and the leaking of the LockBit 3.0 builder — all of which could lead to greater attack volumes.

"\[We have\] high confidence that ransomware will continue to disrupt industrial operations, whether through the integration of \[operational technology\] OT kill processes into ransomware strains, flattened networks allowing for ransomware to spread into OT environments, or through precautionary shutdowns of OT environments by operators to prevent ransomware from spreading to OT systems," Dragos researchers said in the Wednesday report.

Broomhead noted that ramped up attacks are likely being driven by twin engines, including the Russia-Ukraine conflict.

"The rise in ransomware attacks against industrial organizations who rely on OT systems is likely coming from threat actors viewing such organizations as easier victims because OT systems and devices are much more vulnerable than traditional IT systems," he says. "While there may be a rise in targeting industrial organizations because of the conflict in Ukraine, those organizations have been targeted for a long time by several foreign adversaries, therefore this increase is a combination of industrial OT systems being easier to exploit and increased activity due to Ukraine."

Ransomware Gangs Ramp Up Industrial Attacks in US

Older bugs in the AnyConnect Secure Mobility Client are being targeted in the wild, showcasing patch-management failures.

A pair of known security vulnerabilities in the Cisco AnyConnect Secure Mobility Client for Windows is being actively exploited in the wild, despite being patched for two-plus years.

The networking giant is warning that cybercrime groups are pressing two local privilege escalation (LPE) bugs into service, with active exploit chains against the VPN platform being observed starting this month.

The first flaw (CVE-2020-3153, with a CVSS score of 6.5) would allow a logged-in user to send a specially crafted IPC message to the AnyConnect process to perform DLL hijacking and execute arbitrary code on the affected machine with SYSTEM privileges. The second issue (CVE-2020-3433, with a CVSS score of 7.8) could allow a logged-in user to copy arbitrary files to system-level directories with SYSTEM privileges.

"In October 2022, the Cisco Product Security Incident Response Team became aware of additional attempted exploitation of this vulnerability in the wild," Cisco noted in the updated advisories.

The situation showcases the danger that older vulnerabilities continue to pose to companies and individuals. LPE patches are often de-prioritized in the glut of updates that businesses are faced with every month, but exploit chains often combine a remote code execution (RCE) bug for initial access with an LPE exploit for burrowing deeper into corporate networks and uncovering sensitive information.

The US Cybersecurity and Infrastructure Security Agency (CISA) also this week added the bugs to its Known Exploited Vulnerabilities (KEV) catalog, along with four even older bugs in Cisco's Gigabyte gaming and graphics drivers (CVE-2018-19320, CVE-2018-19321, CVE-2018-19322, CVE-2018-19323). Sophos flagged exploitation of the latter earlier in the month by the BlackByte ransomware gang.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Cisco Warns AnyConnect VPNs Under Active Cyberattack

As more of the software stack consists of third-party code, it's time for a more-advanced open source vetting system.

Cyberattacks' frequency and severity remain a growing concern for organizations large and small. Hardly a day goes by without news about a major breach or break-in. Yet it's also clear that methods are evolving and becoming stealthier. One of the more disturbing trends is attackers embedding malware in legitimate products and supply chains.

The SolarWinds attack in 2020 demonstrated just how devastating supply chain attacks can be and how far they can reach. As customers of security firm FireEye downloaded and installed legitimate patches for its Orion IT-monitoring platform, malware hidden in open source software (OSS) code infiltrated their systems.

**No Simple Task**

Gaining control of the software supply chain is vital, yet it's no simple task. OSS has emerged as an essential part of the business world and increasingly delivers critical building blocks used to produce proprietary and commercial software. A growing array of products rooted in the physical world — vehicles, airplanes, medical devices, consumer electronics, and industrial machinery, to name a few — rely on OSS to operate. Hacks and attacks on these systems represent a serious and even potentially fatal risk, ranging from ransomware to sabotage.

Yet the problem is broader. Most software developed today, including applications and code embedded in physical products, contains third-party code that falls into two separate categories:

*   **Pre-built components** that perform a specific function and are available for purchase off-the-shelf, and
*   **Commissioned code** that is developed on an outsourced basis for use in the purchasing company's product.

Both of these types of third-party code can contain embedded and undocumented OSS, which may harbor security vulnerabilities.

**Can You Trust Your Partners?**

Avoiding software supply chain risks is increasingly difficult. Much of the software any organization uses derives from a trusted vendor or partner — or it's a mash-up based on numerous sources. When patches and updates come from trusted sources and appear authentic, there's typically no reason to inspect them. However, if attackers successfully plant malware in legitimate software and it goes undetected through final release production, it can become a mass malware-dissemination tool.

As the SolarWinds attack showed, an organization's defenses are only as good as the supply chain's weakest link. An enterprise can take numerous steps to ensure that the OSS it utilizes is secure, yet it's next-to-impossible to guarantee that the third-party code a partner or vendor supplies is equally vetted. Unfortunately, everyone relies on different techniques, tests, and standards.

While open source code isn't inherently more dangerous than proprietary code, the widespread adoption of OSS means that the same code components can wind up in numerous applications, products, and systems. In fact, roughly 70% to 90% of any software "stack" consists of third-party code. This includes industries and sectors as diverse as public transportation, consumer electronics, telecom, and major software applications used by universities, government agencies, and others.

Moreover, open source code risks are on the rise. Hackers and attackers use several highly effective methods to target resources such as Python repositories (i.e., Python Package Index, or PyPI) and JavaScript package manager npm. This can lead to malware that installs cryptomining software or steals credentials and authentication tokens. An attack can also embed malware in seemingly legitimate code, such as a recent case where 186 npm typosquatting packages appeared in open source code for Linux systems.

**Cracking Down on Bad Code**

Recently, a group of organizations joined together under the umbrella of the Linux Foundation to build a framework for verifying open source code.

This group — OpenSSF (Open Source Security Foundation) — includes heavyweights such as AWS, Google, IBM, and Microsoft, as well as specialized vendors such as Akamai, Indeed, and Socket Security. Its 10-point plan \[PDF\] aims to create more consistent open source code production methods, improve vulnerability discovery and remediation, and reduce patching response times for open source software.

OpenSSF hopes to achieve these results via expanded use of digital signatures on software releases; replacing non-memory-safe languages; standard third-party code reviews; improved education and training for developers and others; and improved tools and best practices for the software supply chain.

All of this leads to a best practice referred to as a software bill of materials (SBOM). It delivers a catalog of OSS as well as other software that's present in third-party (building block) code. It also displays any security vulnerabilities that this software may contain.

**An Eye on Observability**

Getting to a more-advanced open source vetting framework also requires a closer look at the code itself. This is particularly important because organizations not only rely on OSS but also a hybrid approach that revolves around pre-built, off-the-shelf components and custom building blocks, developed internally or by outsourcing partners.

Nearly 60% of software products today contain third-party code, according to VDC Research, most of which uses open source components under the hood. Gaining the needed insight into this code is difficult because conventional software composition analysis (SCA) has inherent limitations. While SCA remains a useful tool for decomposition of software and spotting vulnerabilities, there's also the need to examine and analyze binary files. This makes it possible to scan the code that runs, rather than inspecting only the pieces in the build environment.

Binary SCA finds vulnerabilities in third-party code and OSS without actual source software; it provides deep semantic matching; it's equipped to conduct analysis on real-time code; and it delivers crucial elements such as audit logging, risk reporting, API analysis, and SBOM generation and output, including formats such as PDF, CSV, SPDX, JSON, and CycloneDX. It's a best-practice framework that delivers a comprehensive view of OSS components and other code.

With these pieces in place, it's possible to improve vulnerability detection across all sources of the software in an application or product, boost audit and compliance capabilities, and establish a coveted SBOM. There's no way to stop crooks and cybergangs from attacking organizations through the software supply chain, but the combination of an industry framework and the right inspection technology minimizes the risks and maximizes the gains of open source software.

Open Source Is Just the Tip of the Iceberg in Software Supply Chain Security

New service from BlackBerry's Threat Research and Intelligence Team reduces unknowns to enhance detection and response.

**NEW YORK, Oct. 26, 2022 /PRNewswire/** — Today, at the BlackBerry Security Summit, BlackBerry Limited (NYSE: BB; TSX: BB) announced the release of its new Cyber Threat Intelligence (CTI) offering, a professional threat intelligence service to help customers prevent, detect, and effectively respond to cyberattacks.

Delivered on a quarterly subscription basis, BlackBerry's new CTI service  
provides actionable intelligence on targeted attacks and cybercrime-motivated  
threat actors and campaigns, as well as intelligence reports specific to  
industries, regions, and countries. BlackBerry's CTI will save organizations  
time and resources by focusing on specific areas of interest relevant to a  
company's security goals.

"Being cyber resilient means making the right decisions at the right time," said  
Ismael Valenzuela, Vice President, Threat Research and Intelligence at  
BlackBerry. "Cyberattacks are becoming more sophisticated and threat actors move  
quickly. BlackBerry's Cyber Threat Intelligence delivers the details needed to  
improve detection and response, so organizations can stay on top of cyber threat  
activity and anticipate any next moves."

"More businesses are recognizing the value of threat intelligence and the  
distinctive benefits it brings to security teams," said Chris Kissel, Vice  
President, Security and Trust Products at IDC Research. "Curated threat  
intelligence from credible experts in the space provides businesses and their  
front line security personnel with timely insights, enabling them to better  
detect, triage, and investigate threats. Integrating this service with existing  
security ecosystems helps businesses stay one step ahead of cyber threats as  
digital attack surfaces evolve and expand."

The Threat Research and Intelligence Team has released numerous first-to-market  
research reports over the past year leveraging BlackBerry's data-driven digital  
ecosystem and analytical capabilities. These research reports have revealed new  
developments in the ransomware and malware space, and targeted, state-sponsored  
APT activity, including Symbiote, DCRat, Chaos Yashma ransomware and LokiLocker,  
all of which have been well-received by BlackBerry's customer base and the  
broader security community.

The service will launch in December.

For more information on how BlackBerry's Cyber Threat Intelligence service can  
support your organization, please visit BlackBerry.com to connect with one of  
our experts.

**About BlackBerry**  
BlackBerry (NYSE: BB; TSX: BB) provides intelligent security software and  
services to enterprises and governments around the world. The company secures  
more than 500M endpoints including 215M vehicles. Based in Waterloo, Ontario,  
the company leverages AI and machine learning to deliver innovative solutions in  
the areas of cybersecurity, safety, and data privacy solutions, and is a leader  
in the areas of endpoint security, endpoint management, encryption, and embedded  
systems. BlackBerry's vision is clear — to secure a connected future you can  
trust.

BlackBerry. Intelligent Security. Everywhere.

For more information, visit BlackBerry.com and follow @BlackBerry.

Trademarks, including but not limited to BLACKBERRY and EMBLEM Design are the  
trademarks or registered trademarks of BlackBerry Limited, and the exclusive  
rights to such trademarks are expressly reserved. All other trademarks are the  
property of their respective owners. BlackBerry is not responsible for any  
third-party products or services.

**SOURCE:** BlackBerry Limited

BlackBerry Launches Cyber Threat Intelligence Service to Strengthen Cyber Defenses

The mission to run any containerized application on any infrastructure makes security a challenge on Kubernetes.

Kubernetes is the de facto container management platform in the modern cloud-native world. It makes it possible to develop, deploy, and manage microservices flexibly and scalably. Kubernetes works with various cloud providers, container runtime interfaces, authentication providers, and extensible integration points.

However, Kubernetes still has one major drawback: security. The integrator approach of Kubernetes to run any containerized application on any infrastructure makes it challenging to create holistic security around Kubernetes and the application stack living on it.

According to Red Hat's 2022 "State of Kubernetes" security report, the majority of Kubernetes users had their delivery halted due to unaddressed security concerns. In addition, over the course of the previous 12 months, almost every Kubernetes user in the study experienced at least one security incident. Therefore, it is fair to say that Kubernetes environments are not secure by default and are open to risks.

This article discusses the top 10 security risks with real-life examples and tips on how to avoid them.

**1\. Kubernetes Secrets**

Secrets are one of the core building blocks of Kubernetes for storing sensitive data like passwords, certificates, or tokens and using them inside containers. There are three critical issues related to Kubernetes secrets:

*   Secrets store sensitive data as base-64 encoded strings, but they are not encrypted by default. Kubernetes does offer encryption of the resources for storage, but you need to configure it. Furthermore, the biggest threat about secrets is that any pod — and any applications running inside the pod — in the same namespace can access and read them.
*   Role-based access control (RBAC) allows you to regulate who is granted access to Kubernetes resources. You need to properly configure RBAC rules so that only the relevant people and applications will have access to secrets.
*   Secrets and ConfigMaps are the two methods of passing data to running containers. If there are old and unused secrets or ConfigMap resources, it can create confusion and leak vulnerable data. For instance, if you delete your back-end application deployment but forget to delete the secret that has your database passwords, any malicious pod can use them in the future.

**2\. Container Images With Vulnerabilities**

Kubernetes is a container orchestration platform that distributes and runs containers on the worker nodes. However, it does not check the contents of containers for whether they have security vulnerabilities or exposures.

Therefore, it is necessary to scan the images before deployment to ensure that only images from trusted registries with no critical vulnerabilities (like remote code execution) will run on the cluster. Container image scanning should also be integrated into CI/CD systems for automation and detecting flaws earlier.

**3\. Runtime Threats**

Kubernetes workloads — namely, containers — run on the worker nodes, and the containers are controlled by the host operating system in the runtime. If there are permissive policies or container images with vulnerabilities, they can open backdoors into your whole cluster. Therefore, OS-level runtime protection is required to enforce security in runtime, and the most important protection against runtime threats and vulnerabilities is to implement the least-privileged principle throughout Kubernetes.

Open source and widely accepted tools like Seccomp, SELinux, and AppArmor in the Linux kernel level are available to implement policies and restrict access. These tools are not internal to Kubernetes and require external configuration and effort to enable protection against runtime threats. In order to secure Kubernetes in an automated fashion, try employing the Kubernetes Security Posture Management (KSPM) approach. KSPM leverages automation tools to detect, fix, and alert security, configuration, and compliance issues using a holistic approach.

**4\. Cluster Misconfiguration and Default Settings**

The Kubernetes API and its components consist of a complex set of resource definitions and configuration options. Therefore, Kubernetes offers default values for most of its configuration parameters and tries to remove the burden of creating long YAML files.

However, you need to be careful about three critical issues related to cluster and resource configuration:

*   Default Kubernetes configurations are helpful, as they try to increase flexibility and agility, but they are not always the most secure options.
*   Online examples for Kubernetes resources are helpful to get started, but it is necessary to double-check what these example resource definitions will deploy to your cluster.
*   It is customary to make changes to Kubernetes resources using "kubectl edit" commands while working on the clusters. However, if you forget to update the source files, the changes will be overwritten in the next deployment, and the untracked modifications could lead to unpredictable behavior.

**5\. Kubernetes RBAC Policies**

RBAC is the Kubernetes-native method of managing and controlling authorization to Kubernetes resources. Therefore, configuring and maintaining RBAC policies is essential to secure the clusters from unwanted access.

There are two critical points to consider while working with RBAC policies. First, some RBAC policies are too permissive, such as the cluster\_admin role, which can do basically everything in the cluster. These roles are assigned to regular developers to make them more agile. However, in the event of a security breach, attackers quickly get high-level access to the clusters using cluster\_admin. To avoid this, you should configure RBAC policies for specific resources and assign them to particular user groups.

Second, in general, various environments, like development, testing, staging, and production, exist in the software development life cycle. In addition, there are multiple teams with different focuses, such as developers, testers, operators, and cloud admins. RBAC policies should be assigned correctly for each group and each environment to limit exposure.

**6\. Network Access**

In Kubernetes, a pod can connect to other pods and external addresses outside the cluster; others can connect to this pod from inside the cluster by default. Network policies are the Kubernetes-native resources to manage and restrict the network access between pods, namespaces, and IP blocks.

Network policies can also work with the labels on the pods, so inefficient use of labels could lead to unwanted access. In addition, when the clusters live in cloud providers, the cluster network should also be isolated from the rest of the virtual private cloud (VPC).

**7\. Holistic Monitoring and Audit Logging**

When you deploy an application to a Kubernetes cluster, it's not sufficient to only monitor the application metrics. You must also watch the Kubernetes cluster's status, cloud infrastructure, and cloud controllers to have a holistic view of the complete stack. It is also important to watch for breaches and detect anomalies since intruders will be testing to access your clusters from every possible opening.

Kubernetes provides out-of-the-box audit logs for security-related incidents in the cluster. Still, you also need to collect the records from various applications and monitor their health in a central place.

**8\. Kubernetes API**

Kubernetes API is the core of the entire system, where all internal and external clients connect and communicate with Kubernetes. If you deploy and manage Kubernetes components in-house, you need to be more careful because the Kubernetes API server and its components are open source tools with potential — and actual — vulnerabilities. Therefore, you should use the latest stable version of Kubernetes and patch live clusters as early as possible.

If you use cloud providers, the Kubernetes control plane is in control of the provider itself, so the cloud infrastructure updates and patches automatically. However, users are responsible for upgrading worker nodes in most cases. Therefore, you can use automation and resource provisioning tools to upgrade nodes easily or replace them with new ones.

**9\. Kubernetes Resource Requests and Limits**

In addition to scheduling and running containers, Kubernetes can also limit the resource usage of containers in terms of CPU and memory. Although Kubernetes users mostly neglect them, resource requests and limits are critical for two reasons:

*   **Security:** When the pods and namespaces are not restricted, even a single container with a security vulnerability could access sensitive data inside your cluster.
*   **Cost:** When the requested resources are more than the actual usage, the nodes will run out of available resources. This will lead to an increase in the node pool if autoscaling is enabled, and the new nodes will increase your cloud bill inevitably.

When the resource requests are calculated and assigned correctly, the whole cluster works efficiently in terms of CPU and memory. In addition, when resource limits are set, both faulty applications and intruders will be limited in terms of resource usage. For instance, if there are no resource limitations, a malicious container could consume nearly all of the resources in the node and make your application unusable.

**10\. Data and Storage**

Although containers are designed to be ephemeral, Kubernetes makes it possible to run stateful containerized applications scalably and reliably. With the StatefulSet resource, you can deploy databases, data analytics tools, and machine-learning applications into Kubernetes quickly. The data will be accessible to the pods as volumes attached to the containers.

However, it is critical to limit access by policies and labels to avoid unwanted access by other pods in the cluster. In addition, storage in Kubernetes is provided by external systems, so you should consider using encryption for critical data in the cluster. If you manage your storage plugins, you should also check the security parameters to ensure that they are enabled.

**Conclusion**

Kubernetes is the indisputable container management platform for running microservice applications. However, holistic security is still one of its drawbacks, as it is not the core focus of the project. Therefore, you need to take extra steps to make your clusters and applications more secure.

Top 10 Kubernetes Security Risks Every DevSecOps Pro Should Know

Red Hat Security Advisory 2022-7171-01 - The kernel packages contain the Linux kernel, the core of any Linux operating system. Issues addressed include privilege escalation and use-after-free vulnerabilities.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

====================================================================                     
Red Hat Security Advisory

Synopsis:          Important: kernel security and bug fix update  
Advisory ID:       RHSA-2022:7171-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:7171  
Issue date:        2022-10-25  
CVE Names:         CVE-2022-2588  
====================================================================  
1. Summary:

An update for kernel is now available for Red Hat Enterprise Linux 7.6  
Advanced Update Support, Red Hat Enterprise Linux 7.6 Telco Extended Update  
Support, and Red Hat Enterprise Linux 7.6 Update Services for SAP  
Solutions.

Red Hat Product Security has rated this update as having a security impact  
of Important. A Common Vulnerability Scoring System (CVSS) base score,  
which gives a detailed severity rating, is available for each vulnerability  
from the CVE link(s) in the References section.

2. Relevant releases/architectures:

Red Hat Enterprise Linux Server AUS (v. 7.6) - noarch, x86_64  
Red Hat Enterprise Linux Server E4S (v. 7.6) - noarch, ppc64le, x86_64  
Red Hat Enterprise Linux Server Optional AUS (v. 7.6) - x86_64  
Red Hat Enterprise Linux Server Optional E4S (v. 7.6) - ppc64le, x86_64  
Red Hat Enterprise Linux Server Optional TUS (v. 7.6) - x86_64  
Red Hat Enterprise Linux Server TUS (v. 7.6) - noarch, x86_64

3. Description:

The kernel packages contain the Linux kernel, the core of any Linux  
operating system.

Security Fix(es):

* a use-after-free in cls_route filter implementation may lead to privilege  
escalation (CVE-2022-2588)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

Bug Fix(es):

* backports from upstream for netfilter (BZ#2120635)

4. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.

5. Bugs fixed (https://bugzilla.redhat.com/):

2114849 - CVE-2022-2588 kernel: a use-after-free in cls_route filter implementation may lead to privilege escalation

6. Package List:

Red Hat Enterprise Linux Server AUS (v. 7.6):

Source:  
kernel-3.10.0-957.99.1.el7.src.rpm

noarch:  
kernel-abi-whitelists-3.10.0-957.99.1.el7.noarch.rpm  
kernel-doc-3.10.0-957.99.1.el7.noarch.rpm

x86_64:  
bpftool-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-devel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-common-x86_64-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-devel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-headers-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-libs-3.10.0-957.99.1.el7.x86_64.rpm  
perf-3.10.0-957.99.1.el7.x86_64.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm

Red Hat Enterprise Linux Server E4S (v. 7.6):

Source:  
kernel-3.10.0-957.99.1.el7.src.rpm

noarch:  
kernel-abi-whitelists-3.10.0-957.99.1.el7.noarch.rpm  
kernel-doc-3.10.0-957.99.1.el7.noarch.rpm

ppc64le:  
kernel-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-bootwrapper-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debug-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debuginfo-common-ppc64le-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-devel-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-headers-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-tools-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-tools-libs-3.10.0-957.99.1.el7.ppc64le.rpm  
perf-3.10.0-957.99.1.el7.ppc64le.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
python-perf-3.10.0-957.99.1.el7.ppc64le.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm

x86_64:  
kernel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-devel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-common-x86_64-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-devel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-headers-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-libs-3.10.0-957.99.1.el7.x86_64.rpm  
perf-3.10.0-957.99.1.el7.x86_64.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm

Red Hat Enterprise Linux Server TUS (v. 7.6):

Source:  
kernel-3.10.0-957.99.1.el7.src.rpm

noarch:  
kernel-abi-whitelists-3.10.0-957.99.1.el7.noarch.rpm  
kernel-doc-3.10.0-957.99.1.el7.noarch.rpm

x86_64:  
bpftool-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debug-devel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-common-x86_64-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-devel-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-headers-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-libs-3.10.0-957.99.1.el7.x86_64.rpm  
perf-3.10.0-957.99.1.el7.x86_64.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm

Red Hat Enterprise Linux Server Optional AUS (v. 7.6):

x86_64:  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-common-x86_64-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-libs-devel-3.10.0-957.99.1.el7.x86_64.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm

Red Hat Enterprise Linux Server Optional E4S (v. 7.6):

ppc64le:  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debug-devel-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-debuginfo-common-ppc64le-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
kernel-tools-libs-devel-3.10.0-957.99.1.el7.ppc64le.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.ppc64le.rpm

x86_64:  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-common-x86_64-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-libs-devel-3.10.0-957.99.1.el7.x86_64.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm

Red Hat Enterprise Linux Server Optional TUS (v. 7.6):

x86_64:  
kernel-debug-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-debuginfo-common-x86_64-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
kernel-tools-libs-devel-3.10.0-957.99.1.el7.x86_64.rpm  
perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm  
python-perf-debuginfo-3.10.0-957.99.1.el7.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2022-2588  
https://access.redhat.com/security/updates/classification/#important

8. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBY1gohNzjgjWX9erEAQh9jxAAo0hX0U836zHymb/7X8cI2lgKfgeq8NPl  
lmjvq+JVJ60emyzSrM/tU6/pWrr59SuMN2YuSLU9WgMOFn5q3kMzF0Puht0Vg299  
Uv7UOMhzgJgJIPcZIjfSKULD++vINonnMSEKg5mxEr9YXKHx+wxnYG+1quullwif  
bhxPZFpeNaaovzgGDTIEvAAih04pgoG+4CYbGsN5FtcIbaz6AsON3UruY8fKOftQ  
ZvwzwteOFc6D90ERu/x+NArx9tNhiwjxtFs2gBPOXQ4dDkJZI8NVygbuRh0aqmr9  
lxiFlQqTTXBcwhbCTv7LXYBcGesqpKIaYWMSiWf6s5Vv9qcUOiXKsn7tDJyZUmj3  
0AO6/S5CZZ/i6ziBtUIh5oH4wjcBSNzOzZX6fmDrgq7DSzPeZ/q2BIA13z7bq4w6  
POPMaCsSA/wNotnxlvR3voUDxBAlZ8QgrEt435AmV0nOvncdMgZYqhz18SPe/n7x  
tjBwSfYRzcTJm0oGk5WgDcMofLsQELk4iliqJDL2Td4havr4O+Om0xDQ9oxIX1s5  
GdQ+dHc8Qp0QCCAn74DoI+yz0xLubAFWUF+wKiaVaDAdAe0JWJX4kqaL/I3NqRpO  
gWZDffXyPHnvcEpsOIU7g1q7Mo7ufuFAvKT17CEXSkvJbL4J2JKkxnJWGBWgkVj6  
PdiJqkwxhgQmoq  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-7171-01

Red Hat Security Advisory 2022-7192-01 - The device-mapper-multipath packages provide tools that use the device-mapper multipath kernel module to manage multipath devices. Issues addressed include a bypass vulnerability.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

====================================================================                     
Red Hat Security Advisory

Synopsis:          Important: device-mapper-multipath security update  
Advisory ID:       RHSA-2022:7192-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:7192  
Issue date:        2022-10-25  
CVE Names:         CVE-2022-41974  
====================================================================  
1. Summary:

An update for device-mapper-multipath is now available for Red Hat  
Enterprise Linux 8.

Red Hat Product Security has rated this update as having a security impact  
of Important. A Common Vulnerability Scoring System (CVSS) base score,  
which gives a detailed severity rating, is available for each vulnerability  
from the CVE link(s) in the References section.

2. Relevant releases/architectures:

Red Hat CodeReady Linux Builder (v. 8) - aarch64, ppc64le, s390x, x86_64  
Red Hat Enterprise Linux BaseOS (v. 8) - aarch64, ppc64le, s390x, x86_64

3. Description:

The device-mapper-multipath packages provide tools that use the  
device-mapper multipath kernel module to manage multipath devices.

Security Fix(es):

* device-mapper-multipath: Authorization bypass, multipathd daemon listens  
for client connections on an abstract Unix socket (CVE-2022-41974)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

4. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

5. Bugs fixed (https://bugzilla.redhat.com/):

2133988 - CVE-2022-41974 device-mapper-multipath: Authorization bypass, multipathd daemon listens for client connections on an abstract Unix socket

6. Package List:

Red Hat Enterprise Linux BaseOS (v. 8):

Source:  
device-mapper-multipath-0.8.4-22.el8_6.2.src.rpm

aarch64:  
device-mapper-multipath-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-libs-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm  
kpartx-0.8.4-22.el8_6.2.aarch64.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm  
libdmmp-0.8.4-22.el8_6.2.aarch64.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm

ppc64le:  
device-mapper-multipath-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-libs-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm  
kpartx-0.8.4-22.el8_6.2.ppc64le.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm  
libdmmp-0.8.4-22.el8_6.2.ppc64le.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm

s390x:  
device-mapper-multipath-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-libs-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.s390x.rpm  
kpartx-0.8.4-22.el8_6.2.s390x.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.s390x.rpm  
libdmmp-0.8.4-22.el8_6.2.s390x.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.s390x.rpm

x86_64:  
device-mapper-multipath-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-libs-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-libs-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm  
kpartx-0.8.4-22.el8_6.2.x86_64.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm  
libdmmp-0.8.4-22.el8_6.2.i686.rpm  
libdmmp-0.8.4-22.el8_6.2.x86_64.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm

Red Hat CodeReady Linux Builder (v. 8):

aarch64:  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-devel-0.8.4-22.el8_6.2.aarch64.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.aarch64.rpm

ppc64le:  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-devel-0.8.4-22.el8_6.2.ppc64le.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.ppc64le.rpm

s390x:  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-devel-0.8.4-22.el8_6.2.s390x.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.s390x.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.s390x.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.s390x.rpm

x86_64:  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-debugsource-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-devel-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-devel-0.8.4-22.el8_6.2.x86_64.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
device-mapper-multipath-libs-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
kpartx-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.i686.rpm  
libdmmp-debuginfo-0.8.4-22.el8_6.2.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2022-41974  
https://access.redhat.com/security/updates/classification/#important

8. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBY1go0tzjgjWX9erEAQi1Vg/+Jqqq7oYlPu31HClxrkeh1hRVpKM4wtlL  
dhaxdCntvKop7SGOoivxAy8PwnvdeSS8792yx2UJoErMoDCMvks7wKszTiNsI1Yp  
xZdysfmVj78bnkyMfdYSm9Rqwl4I4bC2endGCz8efVREGAAHKIW/ly3rGqRZnNnG  
N1HMy4v+XSvFtGWX1TDyxLNPkxDDdEKVC/cvns+UDUnIRgQHuO3RJ36ZHnYlF8Ye  
HfDIxt1ux1fS8C5JcVBdsKj1pQ0oUs9qkUsW+qxunSTIaGgSQyT2/L8K3NzrcR5d  
ZZimoDWX65binEYUhvKGNChp3cV3lwEJogcGmyeMpP+bF6WsTMCYB3aYsIeDMB8i  
SBmzsJZlI1Eb1Xk69SNGk55MyURpK2+97op51OTdJlhqQnGxqX0UEDXWv7a1Yt4+  
pXNnEWXRDz621bkJKImYYocvsqeX3xwCFEBJuJphuqK0gtReZb1zWbjNQoh97/Vk  
enZoPwjJVakn228vjq19bcxqtAX6kKLe2aHX3PuX2Dz8v8D4qk4nHRao8mHPfkae  
jBr263ltp8DyKOkpuQM67y84xSpyaaYzgNjlSQcmAC9dNmaVOxB+3p7qINxDnj4e  
rMXIohPsciENFDLa7vFSKhC5bcYiMzd+xat75AuB2V5ExqJioh+GtVVlGNhy756m  
47fa2KnK5Ag=in8Z  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-7192-01

drivers/usb/mon/mon_bin.c in usbmon in the Linux kernel before 5.19.15 and 6.x before 6.0.1 allows a user-space client to corrupt the monitor's internal memory.

commit fbd56ddcecab5a3623a89c8e941fdbcc55b41045 Author: Greg Kroah-Hartman Date: Wed Oct 12 09:39:05 2022 +0200 Linux 6.0.1 Link: https://lore.kernel.org/r/20221010070330.159911806@linuxfoundation.org Tested-by: Luna Jernberg Tested-by: Fenil Jain Tested-by: Linux Kernel Functional Testing Tested-by: Justin M. Forbes Tested-by: Florian Fainelli Tested-by: Ronald Warsow Tested-by: Shuah Khan Tested-by: Zan Aziz Tested-by: Slade Watkins Tested-by: Guenter Roeck Tested-by: Rudi Heitbaum Tested-by: Bagas Sanjaya Tested-by: Jon Hunter Tested-by: Sudip Mukherjee Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman commit 3c6b036fe5c8ed8b6c4cbdc03605929882907ef0 Author: Tetsuo Handa Date: Fri Sep 2 20:23:48 2022 +0900 Bluetooth: use hdev->workqueue when queuing hdev->{cmd,ncmd}\_timer works commit deee93d13d385103205879a8a0915036ecd83261 upstream. syzbot is reporting attempt to schedule hdev->cmd\_work work from system\_wq WQ into hdev->workqueue WQ which is under draining operation \[1\], for commit c8efcc2589464ac7 ("workqueue: allow chained queueing during destruction") does not allow such operation. The check introduced by commit 877afadad2dce8aa ("Bluetooth: When HCI work queue is drained, only queue chained work") was incomplete. Use hdev->workqueue WQ when queuing hdev->{cmd,ncmd}\_timer works because hci\_{cmd,ncmd}\_timeout() calls queue\_work(hdev->workqueue). Also, protect the queuing operation with RCU read lock in order to avoid calling queue\_delayed\_work() after cancel\_delayed\_work() completed. Link: https://syzkaller.appspot.com/bug?extid=243b7d89777f90f7613b \[1\] Reported-by: syzbot Signed-off-by: Tetsuo Handa Fixes: 877afadad2dce8aa ("Bluetooth: When HCI work queue is drained, only queue chained work") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 390ba6a7755d6db79e8000d5501096c24f3b8bfd Author: Jules Irenge Date: Wed Sep 7 16:24:20 2022 +0100 bpf: Fix resetting logic for unreferenced kptrs commit 9fad7fe5b29803584c7f17a2abe6c2936fec6828 upstream. Sparse reported a warning at bpf\_map\_free\_kptrs() "warning: Using plain integer as NULL pointer" During the process of fixing this warning, it was discovered that the current code erroneously writes to the pointer variable instead of deferencing and writing to the actual kptr. Hence, Sparse tool accidentally helped to uncover this problem. Fix this by doing WRITE\_ONCE(\*p, 0) instead of WRITE\_ONCE(p, 0). Note that the effect of this bug is that unreferenced kptrs will not be cleared during check\_and\_free\_fields. It is not a problem if the clearing is not done during map\_free stage, as there is nothing to free for them. Fixes: 14a324f6a67e ("bpf: Wire up freeing of referenced kptr") Signed-off-by: Jules Irenge Link: https://lore.kernel.org/r/Yxi3pJaK6UDjVJSy@playground Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 448faed285b9a0dc4101ffb6a256aa261fcd0979 Author: Daniel Golle Date: Fri Sep 30 01:56:53 2022 +0100 net: ethernet: mtk\_eth\_soc: fix state in \_\_mtk\_foe\_entry\_clear commit ae3ed15da5889263de372ff9df2e83e16acca4cb upstream. Setting ib1 state to MTK\_FOE\_STATE\_UNBIND in \_\_mtk\_foe\_entry\_clear routine as done by commit 0e80707d94e4c8 ("net: ethernet: mtk\_eth\_soc: fix typo in \_\_mtk\_foe\_entry\_clear") breaks flow offloading, at least on older MTK\_NETSYS\_V1 SoCs, OpenWrt users have confirmed the bug on MT7622 and MT7621 systems. Felix Fietkau suggested to use MTK\_FOE\_STATE\_INVALID instead which works well on both, MTK\_NETSYS\_V1 and MTK\_NETSYS\_V2. Tested on MT7622 (Linksys E8450) and MT7986 (BananaPi BPI-R3). Suggested-by: Felix Fietkau Fixes: 0e80707d94e4c8 ("net: ethernet: mtk\_eth\_soc: fix typo in \_\_mtk\_foe\_entry\_clear") Fixes: 33fc42de33278b ("net: ethernet: mtk\_eth\_soc: support creating mac address based offload entries") Signed-off-by: Daniel Golle Link: https://lore.kernel.org/r/YzY+1Yg0FBXcnrtc@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 50fe01fa7640bc216bb1a47754a1f799c20eff8e Author: Kumar Kartikeya Dwivedi Date: Wed Sep 21 16:35:50 2022 +0200 bpf: Gate dynptr API behind CAP\_BPF commit 8addbfc7b308d591f8a5f2f6bb24d08d9d79dfbb upstream. This has been enabled for unprivileged programs for only one kernel release, hence the expected annoyances due to this move are low. Users using ringbuf can stick to non-dynptr APIs. The actual use cases dynptr is meant to serve may not make sense in unprivileged BPF programs. Hence, gate these helpers behind CAP\_BPF and limit use to privileged BPF programs. Fixes: 263ae152e962 ("bpf: Add bpf\_dynptr\_from\_mem for local dynptrs") Fixes: bc34dee65a65 ("bpf: Dynptr support for ring buffers") Fixes: 13bbbfbea759 ("bpf: Add bpf\_dynptr\_read and bpf\_dynptr\_write") Fixes: 34d4ef5775f7 ("bpf: Add dynptr data slices") Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20220921143550.30247-1-memxor@gmail.com Acked-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 64517c21fd0f28b40a75d0d3121276b31399278e Author: Palmer Dabbelt Date: Tue Sep 20 13:45:18 2022 -0700 RISC-V: Print SSTC in canonical order commit 61a41d16ad20657f93613229a8b17766c51dc849 upstream. This got out of order during a merge conflict, fix it by putting the entries in the correct order. Fixes: 7ab52f75a9cf ("RISC-V: Add Sstc extension support") Signed-off-by: Palmer Dabbelt Reviewed-by: Conor Dooley Reviewed-by: Heiko Stuebner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220920204518.10988-1-palmer@rivosinc.com/ Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit d3b5e30e87b52404765b25d9ee156a85c3d8caf6 Author: Mario Limonciello Date: Tue Aug 2 23:25:00 2022 -0500 gpiolib: acpi: Add a quirk for Asus UM325UAZ commit 0ea76c401f9245ac209f1b1ce03a7e1fb9de36e5 upstream. Asus UM325UAZ has GPIO 18 programmed as both an interrupt and a wake source, but confirmed with internal team on this design this pin is floating and shouldn't have been programmed. This causes lots of spurious IRQs on the system and horrendous battery life. Add a quirk to ignore attempts to program this pin on this system. Reported-by: Pavel Krc Link: https://bugzilla.kernel.org/show\_bug.cgi?id=216208 Reviewed-by: Hans de Goede Signed-off-by: Mario Limonciello Reviewed-by: Mika Westerberg Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 359e1b7a7f79738e00a59f367dbe0d3a819d1754 Author: Mario Limonciello Date: Tue Aug 2 23:24:59 2022 -0500 gpiolib: acpi: Add support to ignore programming an interrupt commit 6b6af7bd5718f4e45a9b930533aec1158387d552 upstream. gpiolib-acpi already had support for ignoring a pin for wakeup, but if an OEM configures a floating pin as an interrupt source then stopping it from being a wakeup won't do much good to stop the interrupt storm. Add support for a module parameter and quirk infrastructure to ignore interrupts as well. Signed-off-by: Mario Limonciello Reviewed-by: Hans de Goede Reviewed-by: Mika Westerberg Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 94e14d5193c5692faa589b733e9a360154d4696b Author: Johan Hovold Date: Tue Sep 13 16:53:12 2022 +0200 USB: serial: ftdi\_sio: fix 300 bps rate for SIO commit 7bd7ad3c310cd6766f170927381eea0aa6f46c69 upstream. The 300 bps rate of SIO devices has been mapped to 9600 bps since 2003... Let's fix the regression. Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 08e2c70e549b77f5f3af9c76da00779d5756f997 Author: Tadeusz Struk Date: Mon Sep 19 14:59:57 2022 -0700 usb: mon: make mmapped memory read only commit a659daf63d16aa883be42f3f34ff84235c302198 upstream. Syzbot found an issue in usbmon module, where the user space client can corrupt the monitor's internal memory, causing the usbmon module to crash the kernel with segfault, UAF, etc. The reproducer mmaps the /dev/usbmon memory to user space, and overwrites it with arbitrary data, which causes all kinds of issues. Return an -EPERM error from mon\_bin\_mmap() if the flag VM\_WRTIE is set. Also clear VM\_MAYWRITE to make it impossible to change it to writable later. Cc: "Dmitry Vyukov" Cc: stable Fixes: 6f23ee1fefdc ("USB: add binary API to usbmon") Suggested-by: PaX Team # for the VM\_MAYRITE portion Link: https://syzkaller.appspot.com/bug?id=2eb1f35d6525fa4a74d75b4244971e5b1411c95a Reported-by: syzbot+23f57c5ae902429285d7@syzkaller.appspotmail.com Signed-off-by: Tadeusz Struk Link: https://lore.kernel.org/r/20220919215957.205681-1-tadeusz.struk@linaro.org Signed-off-by: Greg Kroah-Hartman commit 3a93bbb581f85367b3227a685aa24a051230229c Author: Aleksa Savic Date: Wed Sep 14 13:43:27 2022 +0200 hwmon: (aquacomputer\_d5next) Fix Quadro fan speed offsets commit b7f3e9650f12d1e06b94a0257bcb90279f691bf5 upstream. The offsets for setting speeds of fans connected to Quadro are off by one. Set them to their correct values. The offsets as shown point to registers for setting the fan control mode, which will be explored in future patches, but slipped in here. When setting fan speeds, the resulting values were overlapping, which made the fans still run in my initial testing. Fixes: cdbe34da01e3 ("hwmon: (aquacomputer\_d5next) Add support for Aquacomputer Quadro fan controller") Signed-off-by: Aleksa Savic Link: https://lore.kernel.org/r/20220914114327.6941-1-savicaleksa83@gmail.com Cc: stable@vger.kenrel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 4ec318d06084a807df8eb212e321120236915fd6 Author: Shuah Khan Date: Thu Sep 1 15:23:19 2022 -0600 docs: update mediator information in CoC docs commit 8bfdfa0d6b929ede7b6189e0e546ceb6a124d05d upstream. Update mediator information in the CoC interpretation document. Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/20220901212319.56644-1-skhan@linuxfoundation.org Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman commit 49a49d65e21085c088d2a96e583282d59769926b Author: Kees Cook Date: Thu Sep 29 22:57:43 2022 -0700 hardening: Remove Clang's enable flag for -ftrivial-auto-var-init=zero commit 607e57c6c62c00965ae276902c166834ce73014a upstream. Now that Clang's -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang option is no longer required, remove it from the command line. Clang 16 and later will warn when it is used, which will cause Kconfig to think it can't use -ftrivial-auto-var-init=zero at all. Check for whether it is required and only use it when so. Cc: Nathan Chancellor Cc: Masahiro Yamada Cc: Nick Desaulniers Cc: linux-kbuild@vger.kernel.org Cc: llvm@lists.linux.dev Cc: stable@vger.kernel.org Fixes: f02003c860d9 ("hardening: Avoid harmless Clang option under CONFIG\_INIT\_STACK\_ALL\_ZERO") Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit a3c72efe3d6143b0964642435d8d8bf42e4fbf75 Author: Sami Tolvanen Date: Fri Sep 30 20:33:10 2022 +0000 Makefile.extrawarn: Move -Wcast-function-type-strict to W=1 commit 2120635108b35ecad9c59c8b44f6cbdf4f98214e upstream. We enable -Wcast-function-type globally in the kernel to warn about mismatching types in function pointer casts. Compilers currently warn only about ABI incompability with this flag, but Clang 16 will enable a stricter version of the check by default that checks for an exact type match. This will be very noisy in the kernel, so disable -Wcast-function-type-strict without W=1 until the new warnings have been addressed. Cc: stable@vger.kernel.org Link: https://reviews.llvm.org/D134831 Link: https://github.com/ClangBuiltLinux/linux/issues/1724 Suggested-by: Nathan Chancellor Signed-off-by: Sami Tolvanen Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220930203310.4010564-1-samitolvanen@google.com Signed-off-by: Greg Kroah-Hartman commit df3d15181e00f1e63d778c29d252a25e04f6b046 Author: Bart Van Assche Date: Tue Aug 30 13:58:42 2022 -0700 sparc: Unbreak the build commit 17006e86a7641fa3c50324cfb602f0e74dac8527 upstream. Fix the following build errors: arch/sparc/mm/srmmu.c: In function ‘smp\_flush\_page\_for\_dma’: arch/sparc/mm/srmmu.c:1639:13: error: cast between incompatible function types from ‘void (\*)(long unsigned int)’ to ‘void (\*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)’ \[-Werror=cast-function-type\] 1639 | xc1((smpfunc\_t) local\_ops->page\_for\_dma, page); | ^ arch/sparc/mm/srmmu.c: In function ‘smp\_flush\_cache\_mm’: arch/sparc/mm/srmmu.c:1662:29: error: cast between incompatible function types from ‘void (\*)(struct mm\_struct \*)’ to ‘void (\*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)’ \[-Werror=cast-function-type\] 1662 | xc1((smpfunc\_t) local\_ops->cache\_mm, (unsigned long) mm); | \[ ... \] Compile-tested only. Fixes: 552a23a0e5d0 ("Makefile: Enable -Wcast-function-type") Cc: stable@vger.kernel.org Signed-off-by: Bart Van Assche Tested-by: Andreas Larsson Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220830205854.1918026-1-bvanassche@acm.org Signed-off-by: Greg Kroah-Hartman commit 79bc9ee841abf982affb75c8417abe9091e64304 Author: Al Viro Date: Mon Oct 3 20:26:08 2022 -0400 fix coredump breakage commit 4f526fef91b24197d489ff86789744c67f475bb4 upstream. Let me count the ways in which I'd screwed up: \* when emitting a page, handling of gaps in coredump should happen before fetching the current file position. \* fix for a problem that occurs on rather uncommon setups (and hadn't been observed in the wild) had been sent very late in the cycle. \* ... with badly insufficient testing, introducing an easily reproducible breakage. Without giving it time to soak in -next. Fucked-up-by: Al Viro Reported-by: "J. R. Okajima" Tested-by: "J. R. Okajima" Fixes: 06bbaa6dc53c "\[coredump\] don't use \_\_kernel\_write() on kmap\_local\_page()" Cc: stable@kernel.org # v6.0-only Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 2a96b532098284ecf8e4849b8b9e5fc7a28bdee9 Author: Dongliang Mu Date: Tue Aug 16 12:08:58 2022 +0800 fs: fix UAF/GPF bug in nilfs\_mdt\_destroy commit 2e488f13755ffbb60f307e991b27024716a33b29 upstream. In alloc\_inode, inode\_init\_always() could return -ENOMEM if security\_inode\_alloc() fails, which causes inode->i\_private uninitialized. Then nilfs\_is\_metadata\_file\_inode() returns true and nilfs\_free\_inode() wrongly calls nilfs\_mdt\_destroy(), which frees the uninitialized inode->i\_private and leads to crashes(e.g., UAF/GPF). Fix this by moving security\_inode\_alloc just prior to this\_cpu\_inc(nr\_inodes) Link: https://lkml.kernel.org/r/CAFcO6XOcf1Jj2SeGt=jJV59wmhESeSKpfR0omdFRq+J9nD1vfQ@mail.gmail.com Reported-by: butt3rflyh4ck Reported-by: Hao Sun Reported-by: Jiacheng Xu Reviewed-by: Christian Brauner (Microsoft) Signed-off-by: Dongliang Mu Cc: Al Viro Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit a53f14b0a934de4c0ee6935c7ee224e979460a7b Author: Jalal Mostafa Date: Wed Sep 21 13:57:01 2022 +0000 xsk: Inherit need\_wakeup flag for shared sockets commit 60240bc26114543fcbfcd8a28466e67e77b20388 upstream. The flag for need\_wakeup is not set for xsks with \`XDP\_SHARED\_UMEM\` flag and of different queue ids and/or devices. They should inherit the flag from the first socket buffer pool since no flags can be specified once \`XDP\_SHARED\_UMEM\` is specified. Fixes: b5aea28dca134 ("xsk: Add shared umem support between queue ids") Signed-off-by: Jalal Mostafa Signed-off-by: Daniel Borkmann Acked-by: Magnus Karlsson Link: https://lore.kernel.org/bpf/20220921135701.10199-1-jalal.a.mostapha@gmail.com Signed-off-by: Greg Kroah-Hartman

CVE-2022-43750

Red Hat's products are distributed through numerous methods, including RPMs, ISOs and zip files. Over the past several months, we have been working across the organization to design and implement a plan to provide signatures for all zip file types so that our customers have greater assurance that Red Hat actually creates the products they receive. This work is essential to our customers' trust in Red Hat and our products.

Red Hat's products are distributed through numerous methods, including RPMs, ISOs and zip files. Over the past several months, we have been working across the organization to design and implement a plan to provide signatures for all zip file types so that our customers have greater assurance that Red Hat actually creates the products they receive. This work is essential to our customers' trust in Red Hat and our products.

Released on October 4th, 2022, Red Hat Single Sign-On patch 7.5.3 is the first Red Hat zip distribution to include cryptographic signatures. More product releases will come with this vital security metadata in the coming months.

**Background**

Our products are signed with a cryptographic signature to provide evidence that the software has not been tampered with and to verify Red Hat as the software publisher. This provides a higher level of security and assurance for users of our products.

**What are cryptographic signatures?**

Cryptographic signatures are essential for verifying the authenticity and integrity of digital data. They work by verifying both the content creator’s identity and the content’s integrity. Signatures are created using a public and a private key—the public key verifies the signature, while the private key generates it.

**SHA256 hashes**

The Secure Hash Algorithm (SHA) is a cryptographic function to generate a number that identifies a file. It is known as a one-way function since it is easy to compute the hash given the input but very hard to reverse. This characteristic is often known as preimage resistance. SHA also provides "second preimage resistance," meaning that finding another input that would produce the same hash is difficult, even if you know the input. This assures that the file could not have been swapped out in transit or while at rest on our content distribution network (CDN) without a change being detected by the hash.

These characteristics assure our customers that the hash will be different if the file has been tampered with. We have chosen to use the 256-bit variant of the SHA algorithm, which is currently considered secure, and replaces SHA-1, which only provides a 160-bit digest and is known to be vulnerable to preimage attacks.

**RSA signatures**

Red Hat uses RSA signatures (known by the names of its creators, Ron Rivest, Adi Shamir, and Leonard Adleman) to sign lists of SHA256 hashes. RSA is a public-key encryption algorithm considered one of the first successful public-key cryptosystems. It is also considered highly secure when using modern key sizes. The algorithm is based on the fact that it is easy to multiply two large prime numbers together but very difficult to factorize the product. This makes RSA suitable for encryption and digital signatures.

We use a high-strength 4096-bit private key (release key 2), and our public keys are available on our website and the Massachusetts Institute of Technology (MIT) public key server.

**How are we applying these technologies?**

We are first using the security properties of both the SHA256 hash function and the RSA public key cryptosystem to hash all of the files produced for a release and then signing those hashes to confirm that Red Hat produced them. This provides a higher level of security for our releases and helps our customers to detect malicious or accidental corruption.

This process is integrated into our build and release process in two discrete steps: First, hashing the files as part of the build process, and second, packaging and signing the hashes as part of our QE and release verification procedures.

**Hashing the zip file(s)**

Our build system, Brew (powered by koji), produces our RPM and zip distributions and automatically hashes the archives it makes. These hashes are not created by hand; however, they are used to validate that the files have not changed before they are uploaded to our CDN and made available to customers. We have taken advantage of this aspect of our build process and extended it by combining all the hashes for a particular release and packaging them into a "SHA256SUM" file.

This file is in a standard format that lists the hash and the corresponding filename of the particular artifact. It is commonly used across the industry to provide integrity to binary files. However, it is not limited to that. The \`sha256sum\` command on RHEL, other Linux distributions and macOS natively supports this file format.

**Signing the hashes**

Once our software production team has completed their verification procedures, they sign off on the release from both a process and technical perspective. The "SHA256SUM" file they created in the previous step is signed by our latest release key, which produces a \*.asc file. This file is an ASCII-Armor formatted detached signature file that proves the integrity and provenance of the "SHA256SUM" file (and, transitively, the zip artifacts themselves). The "gpg" command on RHEL, other Linux distributions and macOS supports the file format natively.

Due to the potential damage that a lost or stolen private key could cause, we have taken additional steps to add assurance to the signatures we produce. The primary technology behind this is our signing server.

**Signing server**

The signing server is a piece of infrastructure that provides secure access to our private keys to protect them from unauthorized access and use. We use a Hardware Security Module (HSM) to physically prevent the private keys from being exported (reducing the risk of theft). We then restrict the individuals and machines allowed to submit jobs to the signing server using Kerberos authentication and access control lists (ACLs). Our supply chain team carefully maintains and regularly reviews these ACLs to restrict the keys to authorized individuals on certain machines.

Beyond these controls, we also use the signing server to provide auditability and monitoring. Each submission to the server is logged for a minimum of one year within the system log and longer within Splunk. We collect the Kerberos username of the individual and the originating IP address to provide quick and effective incident response and forensics if a breach occurs.

**How does this provide provenance and verification?****Verification**

The SHA256SUM file's signature can be used to verify its integrity. The signature will no longer match if the file has been tampered with. Additionally, the hashes included in the SHA256SUM file can be used to verify the integrity of the downloaded files. These transitive cryptographic guarantees prove the integrity of our releases. Please see our knowledge base article for more details.

**Provenance**

The signature on the zip file can be used to verify the content creator’s identity. Since only specific and authorized individuals have access to use the keys (but not the ability to view or export them), the signature is a way to verify that Red Hat produced the content.

**Summary**

Red Hat now provides a new file for each zip release called "<product> Provenance and Verification." This file contains a SHA256SUM, SHA256SUM.asc, and README.md file, allowing our customers to validate that Red Hat created the release they have acquired. For more information, read **Red Hat Release Provenance and Verification**.

Tag

#mac