Vulnerabilities

PRSD detection denial of service

A cached crafted response can cause an out-of-bounds read if custom Lua code calls getDomainListByAddress() or getAddressListByDomain() on a packet cache.

A rogue backend can send a crafted SVCB response to a Discovery of Designated Resolvers request, when requested via either the autoUpgrade (Lua) option to newServer or auto_upgrade (YAML) settings. DDR upgrade is not enabled by default.

A rogue backend can send a crafted UDP response with a query ID off by one related to the maximum configured value, triggering an out-of-bounds write leading to a denial of service.

An attacker can send a notify request that causes a new secondary domain to be added to the bind backend, but causes said backend to update its configuration to an invalid one, leading to the backend no longer able to run on the next restart, requiring manual operation to fix it.

Incomplete escaping of LDAP queries when running with 8bit-dns enabled allows users to perform queries of internal domain subtrees.

A rogue primary server may cause file descriptor exhaustion and eventually a denial of service, when a PowerDNS secondary server forwards a DNS update request to it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Make sure to use pmu_ctx-&gt;pmu for groups<br /> <br /> Oliver reported that x86_pmu_del() ended up doing an out-of-bound memory access<br /> when group_sched_in() fails and needs to roll back.<br /> <br /> This *should* be handled by the transaction callbacks, but he found that when<br /> the group leader is a software event, the transaction handlers of the wrong PMU<br /> are used. Despite the move_group case in perf_event_open() and group_sched_in()<br /> using pmu_ctx-&gt;pmu.<br /> <br /> Turns out, inherit uses event-&gt;pmu to clone the events, effectively undoing the<br /> move_group case for all inherited contexts. Fix this by also making inherit use<br /> pmu_ctx-&gt;pmu, ensuring all inherited counters end up in the same pmu context.<br /> <br /> Similarly, __perf_event_read() should use equally use pmu_ctx-&gt;pmu for the<br /> group case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/region: Fix leakage in __construct_region()<br /> <br /> Failing the first sysfs_update_group() needs to explicitly<br /> kfree the resource as it is too early for cxl_region_iomem_release()<br /> to do so.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/port: Fix use after free of parent_port in cxl_detach_ep()<br /> <br /> cxl_detach_ep() is called during bottom-up removal when all CXL memory<br /> devices beneath a switch port have been removed. For each port in the<br /> hierarchy it locks both the port and its parent, removes the endpoint,<br /> and if the port is now empty, marks it dead and unregisters the port<br /> by calling delete_switch_port(). There are two places during this work<br /> where the parent_port may be used after freeing:<br /> <br /> First, a concurrent detach may have already processed a port by the<br /> time a second worker finds it via bus_find_device(). Without pinning<br /> parent_port, it may already be freed when we discover port-&gt;dead and<br /> attempt to unlock the parent_port. In a production kernel that&amp;#39;s a<br /> silent memory corruption, with lock debug, it looks like this:<br /> <br /> []DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current())<br /> []WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310<br /> []Call Trace:<br /> []mutex_unlock+0xd/0x20<br /> []cxl_detach_ep+0x180/0x400 [cxl_core]<br /> []devm_action_release+0x10/0x20<br /> []devres_release_all+0xa8/0xe0<br /> []device_unbind_cleanup+0xd/0xa0<br /> []really_probe+0x1a6/0x3e0<br /> <br /> Second, delete_switch_port() releases three devm actions registered<br /> against parent_port. The last of those is unregister_port() and it<br /> calls device_unregister() on the child port, which can cascade. If<br /> parent_port is now also empty the device core may unregister and free<br /> it too. So by the time delete_switch_port() returns, parent_port may<br /> be free, and the subsequent device_unlock(&amp;parent_port-&gt;dev) operates<br /> on freed memory. The kernel log looks same as above, with a different<br /> offset in cxl_detach_ep().<br /> <br /> Both of these issues stem from the absence of a lifetime guarantee<br /> between a child port and its parent port.<br /> <br /> Establish a lifetime rule for ports: child ports hold a reference to<br /> their parent device until release. Take the reference when the port<br /> is allocated and drop it when released. This ensures the parent is<br /> valid for the full lifetime of the child and eliminates the use after<br /> free window in cxl_detach_ep().<br /> <br /> This is easily reproduced with a reload of cxl_acpi in QEMU with CXL<br /> devices present.

A client can trigger a divide by zero error leading to crash by sending a crafted DNSCrypt query.

A client can trigger excessive memory allocation by generating a lot of queries that are routed to an overloaded DoH backend, causing queries to accumulate into a buffer that will not be released until the end of the connection.