An attacker within bluetooth transmission range can cause a stack buffer overflow in the Bluetooth system of the Linux kernel while processing pending L2CAP configuration responses from a client. An unauthenticated user able to connect to a system via Bluetooth could use this flaw to potentially execute arbitrary code with root privileges on the system.
External References:
https://www.armis.com/blueborne/ https://access.redhat.com/security/vulnerabilities/blueborne https://access.redhat.com/solutions/3177231 https://access.redhat.com/blogs/product-security/posts/blueborne
An upstream patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e860d2c904d1a9f38a24eb44c9f34b8f915a6ea3
Last updated 29 November 2024
Mistaken assumptions about the ordering of records in the answer section of a response containing CNAME or DNAME resource records could lead to a situation in which named would exit with an assertion failure when processing a response in which records occurred in an unusual order.
A server which is performing recursion can be forced to exit with an assertion failure if it can be caused to receive a response containing CNAME or DNAME resource records with certain ordering. An attacker can cause a denial of service by exploiting this condition. Recursive resolvers are at highest risk but authoritative servers are theoretically vulnerable if they perform recursion.
External References:
https://kb.isc.org/article/AA-01466
BIND was improperly sequencing cleanup operations on upstream recursion fetch contexts, leading in some cases to a use-after-free error that can trigger an assertion failure and crash in named. Affects BIND 9.0.0 to 9.8.x, 9.9.0 to 9.9.11, 9.10.0 to 9.10.6, 9.11.0 to 9.11.2, 9.9.3-S1 to 9.9.11-S1, 9.10.5-S1 to 9.10.6-S1, 9.12.0a1 to 9.12.0rc1.
ISC BIND 9.8.x through 9.8.4-P1 and 9.9.x through 9.9.2-P1, in certain configurations involving DNS64 with a Response Policy Zone that lacks an AAAA rewrite rule, allows remote attackers to cause a denial of service (assertion failure and named daemon exit) via a query for an AAAA record.
A defect in BIND's handling of responses containing a DNAME answer can cause a resolver to exit after encountering an assertion failure in db.c or resolver.c
During processing of a recursive response that contains a DNAME record in the answer section, BIND can stop execution after encountering an assertion error in resolver.c (error message: "INSIST((valoptions & 0x0002U) != 0) failed") or db.c (error message: "REQUIRE(targetp != ((void )0) && targetp == ((void )0)) failed").
A server encountering either of these error conditions will stop, resulting in denial of service to clients. The risk to authoritative servers is minimal; recursive servers are chiefly at risk.
A flaw was found in the way memory was being allocated on the stack for user space binaries. If heap and stack memory regions were adjacent to each other, an attacker could use this flaw to jump over the heap/stack gap, cause controlled memory corruption on process stack or heap, and thus increase their privileges on the system.
This is a tracking bug for the glibc part of the mitigation.
A denial of service flaw was found in the way BIND handled DNSSEC validation. A remote attacker could use this flaw to make named exit unexpectedly with an assertion failure via a specially crafted DNS response.
A flaw was found in Linux kernel in the KVM virtualization subsystem. The VMX code does not restore the GDT.LIMIT to the previous host value, but instead sets it to 64KB. With a corrupted GDT limit a host's userspace code has an ability to place malicious entries in the GDT, particularly to the per-cpu variables. This can lead to a privilege escalation.
An upstream patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3444d7da1839b851eefedd372978d8a982316c36