Preface: In the ARM architecture, synchronous control is transferred between the normal Non-secure state to Secure state through System Monitor Call exceptions

Background: TEE provides an isolated environment to ensure code/data integrity and confidentiality. A typical embedded system running Linux or Android has vulnerabilities in both the kernel and userspace. Vulnerabilities could allow attackers to access sensitive information or implant malware. TEEs add an extra layer of security where code/data running on TEEs cannot be accessed or tampered with from Linux or Android operating systems.
OP-TEE is designed primarily to rely on the Arm TrustZone technology as the underlying hardware isolation mechanism. However, it has been structured to be compatible with any isolation technology suitable for the TEE concept and goals, such as running as a virtual machine or on a dedicated CPU. The main design goals for OP-TEE are isolation, small footprint and portability.

Vulnerability details:

1. The function cleanup_shm_refs() is called by both entry_invoke_command() and entry_open_session().
2. The commands OPTEE_MSG_CMD_OPEN_SESSION and OPTEE_MSG_CMD_INVOKE_COMMAND can be executed from the normal world via an OP-TEE SMC.
3. This function is not validating the num_params argument, which is only limited to OPTEE_MSG_MAX_NUM_PARAMS (127) in the function get_cmd_buffer().
4. Therefore, an attacker in the normal world can craft an SMC call that will cause out-of-bounds reading in cleanup_shm_refs and potentially freeing of fake-objects in the function mobj_put().

Solution: fix array out of bounds check in cleanup_shm_refs(). Version 3.19.0 contains a fix for this issue. There are no known workarounds.

Official announcement: Please refer to the link for details – https://github.com/OP-TEE/optee_os/commit/728616b28df659cf0bdde6e58a471f6ef25d023c

Preface:For over two decades, developers at some of the world’s most prominent Fortune 500 and Global 2000 companies have trusted Callback Technologies’ components and system drivers to build secure file storage solutions and virtual filesystems. Some of our clients include Amazon, Microsoft, Adobe, Intel, LG, etc.

Background: CBFS Filter allows you to intercept and react to filesystem, registry, and process manager operations as they occur.

ABout CBFS Filter design structure: IOCTL also divides the Buffer into two parts, Input and Output. A single command operation can complete the reading and writing action. The properties of the Buffer also need to be set before it can be used. There are three setting methods: Buffered, Direct and Neither.

If it is for data transmission, it is recommended to use IRP_MJ_READ and IRQP_MJ_WRITE, and for control application, it is recommended to use IRP_MJ_DEVICE_CONTROL.

Ref: Any intermediate driver layered between a file system driver and a removable-media device driver must set up the next-lower-level driver’s I/O stack location in IRPs. From incoming IRP_MJ_READ, IRP_MJ_WRITE, and IRP_MJ_DEVICE_CONTROL requests, the intermediate driver must copy its own I/O stack location Flags into the next-lower-level driver’s I/O stack location when it sets up the I/O stack location for the lower driver, Microsoft said.

Vulnerability details: Cisco Talos found the following. A null pointer dereference vulnerability exists in the handle_ioctl_0x830a0_systembuffer functionality of Callback technologies CBFS Filter 20.0.8317. A specially-crafted I/O request packet (IRP) can lead to denial of service. An attacker can issue an ioctl to trigger this vulnerability.

Official announcement: Please refer to the link for details – https://talosintelligence.com/vulnerability_reports/TALOS-2022-1649

Preface: For example, if an integer data type allows integers up to two bytes or 16 bits in length (or an unsigned number up to decimal 65,535), and two integers are to be added together that will exceed the value of 65,535, the result will be integer overflow.

Background: L2CAP is used within the Bluetooth protocol stack. It passes packets to either the Host Controller Interface (HCI) or, on a hostless system, directly to the Link Manager/ACL link. L2CAP’s functions include: Multiplexing data between different higher layer protocols.In order to provide several data streams, L2CAP uses channels, which are represented by the l2cap_cha structure (include/net/bluetooth/l2cap.h). Current implementation of l2cap_build_conf_req() adding. L2CAP_CONF_RFC(0x04) option to initial configure request sent by the Linux host.

Vulnerability details: A vulnerability was found in Linux Kernel up to 6.0.10 (Operating System). It has been declared as critical. An issue was discovered in the Linux kernel through 6.0.10. l2cap_config_req in net/bluetooth/l2cap_core.c has an integer wraparound via L2CAP_CONF_REQ packets.

Solution: Applying a patch should eliminate this problem.

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2022-45934

Preface: When looking at the systemd Git repository from system250 to system251, there were 79,853 lines of new code and 34,624 lines deleted over the past year.

Background: You are able to use backtrace to track function call stack and locate segment fault under Linux. The (systemd-coredump) collects and displays core core dumps for analyzing application crashes.
By default, systemd-coredump will log the core dump to the journal, furthermore including a backtrace(/usr/lib/systemd/systemd-coredump –backtrace), and store the core dump (an image of the memory contents of the process) itself in an external file in /var/lib/systemd/coredump.
These core dumps are deleted after a few days by default; see /usr/lib/tmpfiles[.]d/systemd.conf for details.

Vulnerability details: systemd 250 and 251 allows local users to achieve a systemd-coredump deadlock by triggering a crash that has a long backtrace. This occurs in parse_elf_object in shared/elf-util[.]c. The exploitation methodology is to crash a binary calling the same function recursively, and put it in a deeply nested directory to make its backtrace large enough to cause the deadlock. This must be done 16 times when MaxConnections=16 is set for the systemd/units/systemd-coredump.socket file.

Remedy: LF is short for Executable and Linkable Format. It’s a format used for storing binaries, libraries, and core dumps on disks in Linux and Unix-based systems. The target remedy file is locate in systemd/src/shared/elf-util[.]c . The elf-util[.]c consists of Iterate over all program headers in that ELF object. These will have been copied by the kernel verbatim when the core file is generated. So this is the reason to modify this file with 31 additions and 6 deletions.

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2022-45873

Ref: Technical details are known, but there is no available exploit.

Preface: There are many ways to do file based IO in Linux. The oldest and most basic are the read(2) and write(2) system calls.
io_uring is a system call interface for Linux. It was first introduced in upstream Linux Kernel version 5.1 in 2019 . It enables an application to initiate system calls that can be performed asynchronously.

Background: In the Linux kernel, reference counting (refcount) has become a default mechanism that manages resource objects. A refcount of a tracked object is incremented when a new reference is assigned and decremented when a reference becomes invalid.
io_uring is a new asynchronous I/O API for Linux created by Jens Axboe from Facebook. It aims at providing an API without the limitations of the current select(2), poll(2), epoll(7) or aio(7) family of system calls.
Reference counting allows clients of your library to keep reference objects created by your library on the heap and allows you to keep track of how many references are still active. When the reference count goes to zero you can safely free the memory used by the object.
The kernel implements reference counting, so the kernel object is not closed until all the file handles pointing to it are closed.

Vulnerability details: Use After Free vulnerability in Linux Kernel allows Privilege Escalation. An improper Update of Reference Count in io_uring leads to Use-After-Free and Local Privilege Escalation. When io_msg_ring was invoked with a fixed file, it called io_fput_file() which improperly decreased its reference count (leading to Use-After-Free and Local Privilege Escalation).

Solution: Applying the patch fc7222c3a9f56271fba02aabbfbae999042f1679 is able to eliminate this problem.

Official announcement: Please refer to the link for details – https://github.com/torvalds/linux/commit/fc7222c3a9f56271fba02aabbfbae999042f1679

Preface:Serverless functions not only make the deployment of new code quicker, simpler, and easy to automate — they also significantly decrease the possibility of downtime during a deploy.To those already familiar with the concepts of Serverless functions, they known Knative introduces some new cyber security challenges.

Background: Knative and the open source advantage Knative allows serverless applications to be deployed and run on any Kubernetes platform, including Red Hat OpenShift Container Platform. Knative installs on OpenShift using Operators. Knative offers features like scale-to-zero, autoscaling, in-cluster builds, and eventing framework for cloud-native applications on Kubernetes. Whether on-premises, in the cloud, or in a third-party data center, Knative codifies the best practices shared by successful real-world Kubernetes-based frameworks.
Knative fall into below categories:

• A simple process that watched a message queue and called other services based on the message payload (in a similar fashion to the classic Message Router EIP)
• Creating an API aggregation or request batching
  Service that exposed a single API endpoint that returned data via the internal orchestration of multiple batched requests to additional upstream services, the aggregated responses.

Vulnerability details: A vulnerability has been found in knative func (knative[.]dev/func) up to 1.8.0. This vulnerability affects an unknown code block. knative[.]dev/func is is a client library and CLI enabling the development and deployment of Kubernetes functions. Developers using a malicious or compromised third-party buildpack could expose their registry credentials or local docker socket to a malicious lifecycle container.

Solution: Upgrading to version 1.8.1 eliminates this vulnerability.

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2022-41939

Preface: Different functional logics are encapsulated into different components/subsystems. From the perspective of the system level, gralloc belongs to the lowest HAL layer module and provides services for the upper-level libui and libgui libraries.
The Gralloc4Allocator in the libui library of the Android framework layer is used as a proxy and encapsulates its functions.

Background: Many components are involved in managing, allocating, and using GraphicBuffer in the Android graphics display system

• Producers and consumers are generally users of GraphicBuffer, either writing data or reading data;
• BufferQueue can be regarded as the manager of GraphicBuffer, which handles requests from users in a unified way, so as to manage the allocation, release and transfer of GraphicBuffer in a unified way;
• Gralloc HAL is the actual cache memory allocation module, which is responsible for allocating graphics buffers that can be shared between processes.

Vulnerability details: In shared_metadata_init of SharedMetadata[.]cpp, there is a possible out of bounds write due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

To read more about std::string_view, please refer to the link for details – https://en.cppreference.com/w/cpp/string/basic_string_view

Official announcement: Please refer to the link for details – https://source.android.com/docs/security/bulletin/pixel/2022-11-01

Preface: Most memory corruption is actually due to heap corruption. To find where the memory address is modified.

1. Set a data breakpoint 0x00408000
2. When you hit the breakpoint, use the memory window to view meory contents starting at 0x00408000.

STR instructions store a register value into memory. The memory address to load from or store to is at an offset from the register Rn . The offset is specified by the register Rm and can be shifted left by up to 3 bits using LSL . The value to load or store can be a byte, halfword, or word.

std::unique_ptr is a smart pointer that owns and manages another object through a pointer and disposes of that object when the unique_ptr goes out of scope.

Background: Mach-O, short for Mach object file format, is a file format for executables, object code, shared libraries, dynamically-loaded code, and core dumps. An executable format determines the order in which the code and data in a binary file are read into memory.
Mach-O is used by some systems based on the Mach kernel. NeXTSTEP, macOS, and iOS are examples of systems that use this format for native executables, libraries and object code.
With the introduction of Mac OS X 10.6 platform the Mach-O file underwent a significant modification that causes binaries compiled on a computer running 10.6 or later to be (by default) executable only on computers running Mac OS X 10.6 or later.

Vulnerability details: A heap buffer overflow in the LIEF::MachO::BinaryParser::parse_dyldinfo_generic_bind function of LIEF v0.12.1 allows attackers to cause a Denial of Service (DoS) via a crafted MachO file.

Official announcement: Please refer to the link for details – https://github.com/lief-project/LIEF/issues/782

Preface: The impact of this flaw (CVE-2022-29279) depends on hardware vendor including smartphone, workstation and using which company SDCard architecture design.

Background: Insyde Software is leading worldwide provider of UEFI firmware systems management (BMC firmware) solutions, and custom engineering services for companies in the mobile, desktop, server, embedded and IoT (Internet-of-Things) computing industries.
SD/SDIO/MMC driver currently supports SD memory, SDIO cards, and eMMC chips. This protocol level driver builds on top of SDMMC and SD SPI host drivers.
SDMMC protocol layer handles specifics of SD protocol such as card initialization and data transfer commands.
Linux kernel has mmc subsystem which provides implementation of host cpu SPI/SDIO implementation, mmc/sd card physical implementation and Linux Block driver implementation based on gendisk.

• /drivers/mmc/core – consists of MMC/SD card related CSD, SID and other commands and responses.
• /drivers/mmc/host – consists of host cpu SPI/ SDIO related implementation.
• /drivers/mmc/card – consists of Linux block driver for MMC card and integration with Linux Block I/O layer.

In Fedora, type following command. cd [/]lib[/]modules[/]$(uname -r)[/]kernel[/]drivers[/].
Then “pwd” it will show you the correct driver location.

A host can communicate with SD/MMC card using a set of commands, and for each command host gets response from the MMC/SD card. These commands and responses have defined format. Each MMC/SD card command has 48 bits (6 bytes).

Vulnerability details: Use of a untrusted pointer allows tampering with SMRAM and OS memory in SdHostDriver and SdMmcDevice Use of a untrusted pointer allows tampering with SMRAM and OS memory in SdHostDriver and SdMmcDevice.

Solution: It was fixed in: Kernel 5.0: version 05.09.17 Kernel 5.1: version 05.17.17 Kernel 5.2: version 05.27.17 Kernel 5.3: version 05.36.17 Kernel 5.4: version 05.44.17 Kernel 5.5: version 05.52.17

Official announcement: Please refer to the link for details – https://www.insyde.com/security-pledge/SA-2022062