Vulnerabilities

A flaw was found in Keycloak, an open-source identity and access management solution. When a client application is configured to accept broad redirect Uniform Resource Identifiers (URIs), a remote attacker can manipulate the authentication process by crafting a special web address. If a user clicks this link, the client application might incorrectly prioritize attacker-controlled information over legitimate data. This vulnerability, known as HTTP parameter pollution, could allow an attacker to bypass security measures or gain unauthorized access to resources.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()<br /> <br /> bareudp_fill_metadata_dst() passes bareudp-&gt;sock to<br /> udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check.<br /> The socket is only created in bareudp_open() and NULLed in<br /> bareudp_stop(), so calling this function while the device is down<br /> triggers a NULL dereference via sock-&gt;sk.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160)<br /> Call Trace:<br /> <br /> bareudp_fill_metadata_dst (drivers/net/bareudp.c:532)<br /> do_execute_actions (net/openvswitch/actions.c:901)<br /> ovs_execute_actions (net/openvswitch/actions.c:1589)<br /> ovs_packet_cmd_execute (net/openvswitch/datapath.c:700)<br /> genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114)<br /> genl_rcv_msg (net/netlink/genetlink.c:1209)<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2550)<br /> <br /> <br /> Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths<br /> in the same driver.

The vulnerability in the Tassos Framework Plugin allows users to delete arbitrary files on the affected sites.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix use-after-free in arena_vm_close on fork<br /> <br /> arena_vm_open() only bumps vml-&gt;mmap_count but never registers the<br /> child VMA in arena-&gt;vma_list. The vml-&gt;vma always points at the<br /> parent VMA, so after parent munmap the pointer dangles. If the child<br /> then calls bpf_arena_free_pages(), zap_pages() reads the stale<br /> vml-&gt;vma triggering use-after-free.<br /> <br /> Fix this by preventing the arena VMA from being inherited across<br /> fork with VM_DONTCOPY, and preventing VMA splits via the may_split<br /> callback.<br /> <br /> Also reject mremap with a .mremap callback returning -EINVAL. A<br /> same-size mremap(MREMAP_FIXED) on the full arena VMA reaches<br /> copy_vma() through the following path:<br /> <br /> check_prep_vma() - returns 0 early: new_len == old_len<br /> skips VM_DONTEXPAND check<br /> prep_move_vma() - vm_start == old_addr and<br /> vm_end == old_addr + old_len<br /> so may_split is never called<br /> move_vma()<br /> copy_vma_and_data()<br /> copy_vma()<br /> vm_area_dup() - copies vm_private_data (vml pointer)<br /> vm_ops-&gt;open() - bumps vml-&gt;mmap_count<br /> vm_ops-&gt;mremap() - returns -EINVAL, rollback unmaps new VMA<br /> <br /> The refcount ensures the rollback&amp;#39;s arena_vm_close does not free<br /> the vml shared with the original VMA.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: fix end-of-list detection in cgroup_storage_get_next_key()<br /> <br /> list_next_entry() never returns NULL -- when the current element is the<br /> last entry it wraps to the list head via container_of(). The subsequent<br /> NULL check is therefore dead code and get_next_key() never returns<br /> -ENOENT for the last element, instead reading storage-&gt;key from a bogus<br /> pointer that aliases internal map fields and copying the result to<br /> userspace.<br /> <br /> Replace it with list_entry_is_head() so the function correctly returns<br /> -ENOENT when there are no more entries.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec()<br /> <br /> CO-RE accessor strings are colon-separated indices that describe a path<br /> from a root BTF type to a target field, e.g. "0:1:2" walks through<br /> nested struct members. bpf_core_parse_spec() parses each component with<br /> sscanf("%d"), so negative values like -1 are silently accepted. The<br /> subsequent bounds checks (access_idx &gt;= btf_vlen(t)) only guard the<br /> upper bound and always pass for negative values because C integer<br /> promotion converts the __u16 btf_vlen result to int, making the<br /> comparison (int)(-1) &gt;= (int)(N) false for any positive N.<br /> <br /> When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff,<br /> producing an out-of-bounds read far past the members array. A crafted<br /> BPF program with a negative CO-RE accessor on any struct that exists in<br /> vmlinux BTF (e.g. task_struct) crashes the kernel deterministically<br /> during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y<br /> (default on major distributions). The bug is reachable with CAP_BPF:<br /> <br /> BUG: unable to handle page fault for address: ffffed11818b6626<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> Oops: Oops: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full)<br /> RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354)<br /> RAX: 00000000ffffffff<br /> Call Trace:<br /> <br /> bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321)<br /> bpf_core_apply (kernel/bpf/btf.c:9507)<br /> check_core_relo (kernel/bpf/verifier.c:19475)<br /> bpf_check (kernel/bpf/verifier.c:26031)<br /> bpf_prog_load (kernel/bpf/syscall.c:3089)<br /> __sys_bpf (kernel/bpf/syscall.c:6228)<br /> <br /> <br /> CO-RE accessor indices are inherently non-negative (struct member index,<br /> array element index, or enumerator index), so reject them immediately<br /> after parsing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openvswitch: cap upcall PID array size and pre-size vport replies<br /> <br /> The vport netlink reply helpers allocate a fixed-size skb with<br /> nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID<br /> array via ovs_vport_get_upcall_portids(). Since<br /> ovs_vport_set_upcall_portids() accepts any non-zero multiple of<br /> sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID<br /> array large enough to overflow the reply buffer, causing nla_put() to<br /> fail with -EMSGSIZE and hitting BUG_ON(err

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO<br /> <br /> nf_osf_match_one() computes ctx-&gt;window % f-&gt;wss.val in the<br /> OSF_WSS_MODULO branch with no guard for f-&gt;wss.val == 0. A<br /> CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a<br /> subsequent matching TCP SYN divides by zero and panics the kernel.<br /> <br /> Reject the bogus fingerprint in nfnl_osf_add_callback() above the<br /> per-option for-loop. f-&gt;wss is per-fingerprint, not per-option, so<br /> the check must run regardless of f-&gt;opt_num (including 0). Also<br /> reject wss.wc &gt;= OSF_WSS_MAX; nf_osf_match_one() already treats that<br /> as "should not happen".<br /> <br /> Crash:<br /> Oops: divide error: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98)<br /> Call Trace:<br /> <br /> nf_osf_match (net/netfilter/nfnetlink_osf.c:220)<br /> xt_osf_match_packet (net/netfilter/xt_osf.c:32)<br /> ipt_do_table (net/ipv4/netfilter/ip_tables.c:348)<br /> nf_hook_slow (net/netfilter/core.c:622)<br /> ip_local_deliver (net/ipv4/ip_input.c:265)<br /> ip_rcv (include/linux/skbuff.h:1162)<br /> __netif_receive_skb_one_core (net/core/dev.c:6181)<br /> process_backlog (net/core/dev.c:6642)<br /> __napi_poll (net/core/dev.c:7710)<br /> net_rx_action (net/core/dev.c:7945)<br /> handle_softirqs (kernel/softirq.c:622)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slip: reject VJ receive packets on instances with no rstate array<br /> <br /> slhc_init() accepts rslots == 0 as a valid configuration, with the<br /> documented meaning of &amp;#39;no receive compression&amp;#39;. In that case the<br /> allocation loop in slhc_init() is skipped, so comp-&gt;rstate stays<br /> NULL and comp-&gt;rslot_limit stays 0 (from the kzalloc of struct<br /> slcompress).<br /> <br /> The receive helpers do not defend against that configuration.<br /> slhc_uncompress() dereferences comp-&gt;rstate[x] when the VJ header<br /> carries an explicit connection ID, and slhc_remember() later assigns<br /> cs = &amp;comp-&gt;rstate[...] after only comparing the packet&amp;#39;s slot number<br /> to comp-&gt;rslot_limit. Because rslot_limit is 0, slot 0 passes the<br /> range check, and the code dereferences a NULL rstate.<br /> <br /> The configuration is reachable in-tree through PPP. PPPIOCSMAXCID<br /> stores its argument in a signed int, and (val &gt;&gt; 16) uses arithmetic<br /> shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1<br /> is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because<br /> /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path<br /> is reachable from an unprivileged user namespace. Once the malformed<br /> VJ state is installed, any inbound VJ-compressed or VJ-uncompressed<br /> frame that selects slot 0 crashes the kernel in softirq context:<br /> <br /> Oops: general protection fault, probably for non-canonical<br /> address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519)<br /> Call Trace:<br /> <br /> ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466)<br /> ppp_input (drivers/net/ppp/ppp_generic.c:2359)<br /> ppp_async_process (drivers/net/ppp/ppp_async.c:492)<br /> tasklet_action_common (kernel/softirq.c:926)<br /> handle_softirqs (kernel/softirq.c:623)<br /> run_ksoftirqd (kernel/softirq.c:1055)<br /> smpboot_thread_fn (kernel/smpboot.c:160)<br /> kthread (kernel/kthread.c:436)<br /> ret_from_fork (arch/x86/kernel/process.c:164)<br /> <br /> <br /> Reject the receive side on such instances instead of touching rstate.<br /> slhc_uncompress() falls through to its existing &amp;#39;bad&amp;#39; label, which<br /> bumps sls_i_error and enters the toss state. slhc_remember() mirrors<br /> that with an explicit sls_i_error increment followed by slhc_toss();<br /> the sls_i_runt counter is not used here because a missing rstate is<br /> an internal configuration state, not a runt packet.<br /> <br /> The transmit path is unaffected: the only in-tree caller that picks<br /> rslots from userspace (ppp_generic.c) still supplies tslots &gt;= 1, and<br /> slip.c always calls slhc_init(16, 16), so comp-&gt;tstate remains valid<br /> and slhc_compress() continues to work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slip: bound decode() reads against the compressed packet length<br /> <br /> slhc_uncompress() parses a VJ-compressed TCP header by advancing a<br /> pointer through the packet via decode() and pull16(). Neither helper<br /> bounds-checks against isize, and decode() masks its return with<br /> &amp; 0xffff so it can never return the -1 that callers test for -- those<br /> error paths are dead code.<br /> <br /> A short compressed frame whose change byte requests optional fields<br /> lets decode() read past the end of the packet. The over-read bytes<br /> are folded into the cached cstate and reflected into subsequent<br /> reconstructed packets.<br /> <br /> Make decode() and pull16() take the packet end pointer and return -1<br /> when exhausted. Add a bounds check before the TCP-checksum read.<br /> The existing == -1 tests now do what they were always meant to.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: arp_tables: fix IEEE1394 ARP payload parsing<br /> <br /> Weiming Shi says:<br /> <br /> "arp_packet_match() unconditionally parses the ARP payload assuming two<br /> hardware addresses are present (source and target). However,<br /> IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address<br /> field, and arp_hdr_len() already accounts for this by returning a<br /> shorter length for ARPHRD_IEEE1394 devices.<br /> <br /> As a result, on IEEE1394 interfaces arp_packet_match() advances past a<br /> nonexistent target hardware address and reads the wrong bytes for both<br /> the target device address comparison and the target IP address. This<br /> causes arptables rules to match against garbage data, leading to<br /> incorrect filtering decisions: packets that should be accepted may be<br /> dropped and vice versa.<br /> <br /> The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already<br /> handles this correctly by skipping the target hardware address for<br /> ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match()."<br /> <br /> Mangle the original patch to always return 0 (no match) in case user<br /> matches on the target hardware address which is never present in<br /> IEEE1394.<br /> <br /> Note that this returns 0 (no match) for either normal and inverse match<br /> because matching in the target hardware address in ARPHRD_IEEE1394 has<br /> never been supported by arptables. This is intentional, matching on the<br /> target hardware address should never evaluate true for ARPHRD_IEEE1394.<br /> <br /> Moreover, adjust arpt_mangle to drop the packet too as AI suggests:<br /> <br /> In arpt_mangle, the logic assumes a standard ARP layout. Because<br /> IEEE1394 (FireWire) omits the target hardware address, the linear<br /> pointer arithmetic miscalculates the offset for the target IP address.<br /> This causes mangling operations to write to the wrong location, leading<br /> to packet corruption. To ensure safety, this patch drops packets<br /> (NF_DROP) when mangling is requested for these fields on IEEE1394<br /> devices, as the current implementation cannot correctly map the FireWire<br /> ARP payload.<br /> <br /> This omits both mangling target hardware and IP address. Even if IP<br /> address mangling should be possible in IEEE1394, this would require<br /> to adjust arpt_mangle offset calculation, which has never been<br /> supported.<br /> <br /> Based on patch from Weiming Shi .

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: taprio: fix NULL pointer dereference in class dump<br /> <br /> When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft()<br /> is called with new == NULL and stores NULL into q-&gt;qdiscs[cl - 1].<br /> Subsequent RTM_GETTCLASS dump operations walk all classes via<br /> taprio_walk() and call taprio_dump_class(), which calls taprio_leaf()<br /> returning the NULL pointer, then dereferences it to read child-&gt;handle,<br /> causing a kernel NULL pointer dereference.<br /> <br /> The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel<br /> with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user<br /> namespaces enabled, an unprivileged local user can trigger a kernel<br /> panic by creating a taprio qdisc inside a new network namespace,<br /> grafting an explicit child qdisc, deleting it, and requesting a class<br /> dump. The RTM_GETTCLASS dump itself requires no capability.<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]<br /> RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2478)<br /> Call Trace:<br /> <br /> tc_fill_tclass (net/sched/sch_api.c:1966)<br /> qdisc_class_dump (net/sched/sch_api.c:2326)<br /> taprio_walk (net/sched/sch_taprio.c:2514)<br /> tc_dump_tclass_qdisc (net/sched/sch_api.c:2352)<br /> tc_dump_tclass_root (net/sched/sch_api.c:2370)<br /> tc_dump_tclass (net/sched/sch_api.c:2431)<br /> rtnl_dumpit (net/core/rtnetlink.c:6864)<br /> netlink_dump (net/netlink/af_netlink.c:2325)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:6959)<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2550)<br /> <br /> <br /> Fix this by substituting &amp;noop_qdisc when new is NULL in<br /> taprio_graft(), a common pattern used by other qdiscs (e.g.,<br /> multiq_graft()) to ensure the q-&gt;qdiscs[] slots are never NULL.<br /> This makes control-plane dump paths safe without requiring individual<br /> NULL checks.<br /> <br /> Since the data-plane paths (taprio_enqueue and taprio_dequeue_from_txq)<br /> previously had explicit NULL guards that would drop/skip the packet<br /> cleanly, update those checks to test for &amp;noop_qdisc instead. Without<br /> this, packets would reach taprio_enqueue_one() which increments the root<br /> qdisc&amp;#39;s qlen and backlog before calling the child&amp;#39;s enqueue; noop_qdisc<br /> drops the packet but those counters are never rolled back, permanently<br /> inflating the root qdisc&amp;#39;s statistics.<br /> <br /> After this change *old can be a valid qdisc, NULL, or &amp;noop_qdisc.<br /> Only call qdisc_put(*old) in the first case to avoid decreasing<br /> noop_qdisc&amp;#39;s refcount, which was never increased.