#dos

Ubuntu Security Notice 5668-1 - It was discovered that the BPF verifier in the Linux kernel did not properly handle internal data structures. A local attacker could use this to expose sensitive information. It was discovered that an out-of-bounds write vulnerability existed in the Video for Linux 2 implementation in the Linux kernel. A local attacker could use this to cause a denial of service or possibly execute arbitrary code.

Ubuntu Security Notice 5669-2 - It was discovered that the SUNRPC RDMA protocol implementation in the Linux kernel did not properly calculate the header size of a RPC message payload. A local attacker could use this to expose sensitive information. Moshe Kol, Amit Klein and Yossi Gilad discovered that the IP implementation in the Linux kernel did not provide sufficient randomization when calculating port offsets. An attacker could possibly use this to expose sensitive information.

Ubuntu Security Notice 5657-1 - It was discovered that Graphite2 mishandled specially crafted files. An attacker could possibly use this issue to cause a denial of service or other unspecified impact.

Ubuntu Security Notice 5665-1 - It was discovered that PCRE incorrectly handled certain regular expressions. A remote attacker could use this issue to cause applications using PCRE to crash, resulting in a denial of service. It was discovered that PCRE incorrectly handled certain Unicode encoding. A remote attacker could use this issue to cause applications using PCRE to crash, resulting in a denial of service.

Traefik (pronounced traffic) is a modern HTTP reverse proxy and load balancer that assists in deploying microservices. There is a potential vulnerability in Traefik managing HTTP/2 connections. A closing HTTP/2 server connection could hang forever because of a subsequent fatal error. This failure mode could be exploited to cause a denial of service. There has been a patch released in versions 2.8.8 and 2.9.0-rc5. There are currently no known workarounds.

### Impact An attacker can send an invalid `Content-Type` header that can cause the application to crash, leading to a possible Denial of Service attack. Only the v4.x line is affected. (This was updated: upon a close inspection, v3.x is not affected after all). ### Patches Yes, update to `> v4.8.0`. ### Workarounds You can reject the malicious content types before the body parser enters in action. ```js const badNames = Object.getOwnPropertyNames({}.__proto__) fastify.addHook('onRequest', async (req, reply) => { for (const badName of badNames) { if (req.headers['content-type'].indexOf(badName) > -1) { reply.code(415) throw new Error('Content type not supported') } } }) ``` ### References See the HackerOne report [#1715536](https://hackerone.com/bugs?report_id=1715536&subject=fastify) ### For more information [Fastify security policy](https://github.com/fastify/fastify/security/policy)

Arm: unbounded memory consumption for 2nd-level page tables Certain actions require e.g. removing pages from a guest's P2M (Physical-to-Machine) mapping. When large pages are in use to map guest pages in the 2nd-stage page tables, such a removal operation may incur a memory allocation (to replace a large mapping with individual smaller ones). These memory allocations are taken from the global memory pool. A malicious guest might be able to cause the global memory pool to be exhausted by manipulating its own P2M mappings.

XAPI open file limit DoS It is possible for an unauthenticated client on the network to cause XAPI to hit its file-descriptor limit. This causes XAPI to be unable to accept new requests for other (trusted) clients, and blocks XAPI from carrying out any tasks that require the opening of file descriptors.

lock order inversion in transitive grant copy handling As part of XSA-226 a missing cleanup call was inserted on an error handling path. While doing so, locking requirements were not paid attention to. As a result two cooperating guests granting each other transitive grants can cause locks to be acquired nested within one another, but in respectively opposite order. With suitable timing between the involved grant copy operations this may result in the locking up of a CPU.

P2M pool freeing may take excessively long The P2M pool backing second level address translation for guests may be of significant size. Therefore its freeing may take more time than is reasonable without intermediate preemption checks. Such checking for the need to preempt was so far missing.