Vulnerabilities

The Registrations for the Events Calendar WordPress plugin before 2.12.4 does not sanitise and escape some parameters when accepting event registrations, which could allow unauthenticated users to perform Cross-Site Scripting attacks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages<br /> <br /> Avoid memory corruption while setting up Level-2 PBL pages for the non MR<br /> resources when num_pages &gt; 256K.<br /> <br /> There will be a single PDE page address (contiguous pages in the case of &gt;<br /> PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid<br /> memory access after 256K PBL entries in the PDE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: Add a check for memory allocation<br /> <br /> __alloc_pbl() can return error when memory allocation fails.<br /> Driver is not checking the status on one of the instances.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()<br /> <br /> If get_clock_desc() succeeds, it calls fget() for the clockid&amp;#39;s fd,<br /> and get the clk-&gt;rwsem read lock, so the error path should release<br /> the lock to make the lock balance and fput the clockid&amp;#39;s fd to make<br /> the refcount balance and release the fd related resource.<br /> <br /> However the below commit left the error path locked behind resulting in<br /> unbalanced locking. Check timespec64_valid_strict() before<br /> get_clock_desc() to fix it, because the "ts" is not changed<br /> after that.<br /> <br /> [pabeni@redhat.com: fixed commit message typo]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: intel: platform: fix error path in device_for_each_child_node()<br /> <br /> The device_for_each_child_node() loop requires calls to<br /> fwnode_handle_put() upon early returns to decrement the refcount of<br /> the child node and avoid leaking memory if that error path is triggered.<br /> <br /> There is one early returns within that loop in<br /> intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is<br /> missing.<br /> <br /> Instead of adding the missing call, the scoped version of the loop can<br /> be used to simplify the code and avoid mistakes in the future if new<br /> early returns are added, as the child node is only used for parsing, and<br /> it is never assigned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Fix address emission with tag-based KASAN enabled<br /> <br /> When BPF_TRAMP_F_CALL_ORIG is enabled, the address of a bpf_tramp_image<br /> struct on the stack is passed during the size calculation pass and<br /> an address on the heap is passed during code generation. This may<br /> cause a heap buffer overflow if the heap address is tagged because<br /> emit_a64_mov_i64() will emit longer code than it did during the size<br /> calculation pass. The same problem could occur without tag-based<br /> KASAN if one of the 16-bit words of the stack address happened to<br /> be all-ones during the size calculation pass. Fix the problem by<br /> assuming the worst case (4 instructions) when calculating the size<br /> of the bpf_tramp_image address emission.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: don&amp;#39;t try and remove empty rbtree node<br /> <br /> When copying a namespace we won&amp;#39;t have added the new copy into the<br /> namespace rbtree until after the copy succeeded. Calling free_mnt_ns()<br /> will try to remove the copy from the rbtree which is invalid. Simply<br /> free the namespace skeleton directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init<br /> <br /> The loop responsible for allocating up to MTK_FQ_DMA_LENGTH buffers must<br /> only touch as many descriptors, otherwise it ends up corrupting unrelated<br /> memory. Fix the loop iteration count accordingly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gic-v4: Don&amp;#39;t allow a VMOVP on a dying VPE<br /> <br /> Kunkun Jiang reported that there is a small window of opportunity for<br /> userspace to force a change of affinity for a VPE while the VPE has already<br /> been unmapped, but the corresponding doorbell interrupt still visible in<br /> /proc/irq/.<br /> <br /> Plug the race by checking the value of vmapp_count, which tracks whether<br /> the VPE is mapped ot not, and returning an error in this case.<br /> <br /> This involves making vmapp_count common to both GICv4.1 and its v4.0<br /> ancestor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/entry_32: Clear CPU buffers after register restore in NMI return<br /> <br /> CPU buffers are currently cleared after call to exc_nmi, but before<br /> register state is restored. This may be okay for MDS mitigation but not for<br /> RDFS. Because RDFS mitigation requires CPU buffers to be cleared when<br /> registers don&amp;#39;t have any sensitive data.<br /> <br /> Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: probes: Fix uprobes for big-endian kernels<br /> <br /> The arm64 uprobes code is broken for big-endian kernels as it doesn&amp;#39;t<br /> convert the in-memory instruction encoding (which is always<br /> little-endian) into the kernel&amp;#39;s native endianness before analyzing and<br /> simulating instructions. This may result in a few distinct problems:<br /> <br /> * The kernel may may erroneously reject probing an instruction which can<br /> safely be probed.<br /> <br /> * The kernel may erroneously erroneously permit stepping an<br /> instruction out-of-line when that instruction cannot be stepped<br /> out-of-line safely.<br /> <br /> * The kernel may erroneously simulate instruction incorrectly dur to<br /> interpretting the byte-swapped encoding.<br /> <br /> The endianness mismatch isn&amp;#39;t caught by the compiler or sparse because:<br /> <br /> * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so<br /> the compiler and sparse have no idea these contain a little-endian<br /> 32-bit value. The core uprobes code populates these with a memcpy()<br /> which similarly does not handle endianness.<br /> <br /> * While the uprobe_opcode_t type is an alias for __le32, both<br /> arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]<br /> to the similarly-named probe_opcode_t, which is an alias for u32.<br /> Hence there is no endianness conversion warning.<br /> <br /> Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and<br /> adding the appropriate __le32_to_cpu() conversions prior to consuming<br /> the instruction encoding. The core uprobes copies these fields as opaque<br /> ranges of bytes, and so is unaffected by this change.<br /> <br /> At the same time, remove MAX_UINSN_BYTES and consistently use<br /> AARCH64_INSN_SIZE for clarity.<br /> <br /> Tested with the following:<br /> <br /> | #include <br /> | #include <br /> |<br /> | #define noinline __attribute__((noinline))<br /> |<br /> | static noinline void *adrp_self(void)<br /> | {<br /> | void *addr;<br /> |<br /> | asm volatile(<br /> | " adrp %x0, adrp_self\n"<br /> | " add %x0, %x0, :lo12:adrp_self\n"<br /> | : "=r" (addr));<br /> | }<br /> |<br /> |<br /> | int main(int argc, char *argv)<br /> | {<br /> | void *ptr = adrp_self();<br /> | bool equal = (ptr == adrp_self);<br /> |<br /> | printf("adrp_self =&gt; %p\n"<br /> | "adrp_self() =&gt; %p\n"<br /> | "%s\n",<br /> | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL");<br /> |<br /> | return 0;<br /> | }<br /> <br /> .... where the adrp_self() function was compiled to:<br /> <br /> | 00000000004007e0 :<br /> | 4007e0: 90000000 adrp x0, 400000 <br /> | 4007e4: 911f8000 add x0, x0, #0x7e0<br /> | 4007e8: d65f03c0 ret<br /> <br /> Before this patch, the ADRP is not recognized, and is assumed to be<br /> steppable, resulting in corruption of the result:<br /> <br /> | # ./adrp-self<br /> | adrp_self =&gt; 0x4007e0<br /> | adrp_self() =&gt; 0x4007e0<br /> | EQUAL<br /> | # echo &amp;#39;p /root/adrp-self:0x007e0&amp;#39; &gt; /sys/kernel/tracing/uprobe_events<br /> | # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable<br /> | # ./adrp-self<br /> | adrp_self =&gt; 0x4007e0<br /> | adrp_self() =&gt; 0xffffffffff7e0<br /> | NOT EQUAL<br /> <br /> After this patch, the ADRP is correctly recognized and simulated:<br /> <br /> | # ./adrp-self<br /> | adrp_self =&gt; 0x4007e0<br /> | adrp_self() =&gt; 0x4007e0<br /> | EQUAL<br /> | #<br /> | # echo &amp;#39;p /root/adrp-self:0x007e0&amp;#39; &gt; /sys/kernel/tracing/uprobe_events<br /> | # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable<br /> | # ./adrp-self<br /> | adrp_self =&gt; 0x4007e0<br /> | adrp_self() =&gt; 0x4007e0<br /> | EQUAL

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> posix-clock: Fix missing timespec64 check in pc_clock_settime()<br /> <br /> As Andrew pointed out, it will make sense that the PTP core<br /> checked timespec64 struct&amp;#39;s tv_sec and tv_nsec range before calling<br /> ptp-&gt;info-&gt;settime64().<br /> <br /> As the man manual of clock_settime() said, if tp.tv_sec is negative or<br /> tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,<br /> which include dynamic clocks which handles PTP clock, and the condition is<br /> consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()<br /> only check the timespec is valid, but not ensure that the time is<br /> in a valid range, so check it ahead using timespec64_valid_strict()<br /> in pc_clock_settime() and return -EINVAL if not valid.<br /> <br /> There are some drivers that use tp-&gt;tv_sec and tp-&gt;tv_nsec directly to<br /> write registers without validity checks and assume that the higher layer<br /> has checked it, which is dangerous and will benefit from this, such as<br /> hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),<br /> and some drivers can remove the checks of itself.