Vulnerabilities

When<br /> a certificate and its private key are installed in the Windows machine<br /> certificate store using Network and Security tool, access rights to the private<br /> key are unnecessarily <br /> <br /> granted to the operator group.<br /> <br /> <br /> <br /> <br /> * Installations based on Panorama Suite 2025 (25.00.004) are vulnerable unless update PS-2500-00-0357 (or higher) is installed<br /> * <br /> Installations based on Panorama Suite 2025 Updated Dec. 25 (25.10.007) are not vulnerable<br /> <br /> <br /> Please refer to security bulletin BS-036, available on the Panorama CSIRT website:  https://my.codra.net/en-gb/csirt .

From<br /> Panorama Web HMI, an attacker can gain read access to certain Web HMI server<br /> files, if he knows their paths and if these files are accessible to the Servin<br /> process execution account.<br /> <br /> * Installations based on Panorama Suite 2022-SP1 (22.50.005) are vulnerable unless update PS-2210-02-4079 (or higher) is installed<br /> * Installations based on Panorama Suite 2023 (23.00.004) are vulnerable <br /> unless updates PS-2300-03-3078 (or higher) and PS-2300-04-3078 (or higher)<br /> and PS-2300-82-3078<br /> <br /> (or higher)<br /> <br /> are installed<br /> * Installations based on Panorama Suite 2025 (25.00.016)<br /> <br /> are vulnerable unless updates PS-2500-02-1078 (or higher) and PS-2500-04-1078 (or higher) are installed <br /> * Installations based on Panorama Suite 2025 Updated Dec. 25 (25.10.007)<br /> <br /> are vulnerable unless updates PS-2510-02-1077 (or higher) and PS-2510-04-1077 (or higher)<br /> <br /> are installed<br /> <br /> <br /> <br /> <br /> Please refer to security bulletin BS-035, available on the Panorama CSIRT website:  https://my.codra.net/en-gb/csirt .

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: cfm: Fix race condition in peer_mep deletion<br /> <br /> When a peer MEP is being deleted, cancel_delayed_work_sync() is called<br /> on ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in<br /> softirq context under rcu_read_lock (without RTNL) and can re-schedule<br /> ccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync()<br /> returning and kfree_rcu() being called.<br /> <br /> The following is a simple race scenario:<br /> <br /> cpu0 cpu1<br /> <br /> mep_delete_implementation()<br /> cancel_delayed_work_sync(ccm_rx_dwork);<br /> br_cfm_frame_rx()<br /> // peer_mep still in hlist<br /> if (peer_mep-&gt;ccm_defect)<br /> ccm_rx_timer_start()<br /> queue_delayed_work(ccm_rx_dwork)<br /> hlist_del_rcu(&amp;peer_mep-&gt;head);<br /> kfree_rcu(peer_mep, rcu);<br /> ccm_rx_work_expired()<br /> // on freed peer_mep<br /> <br /> To prevent this, cancel_delayed_work_sync() is replaced with<br /> disable_delayed_work_sync() in both peer MEP deletion paths, so<br /> that subsequent queue_delayed_work() calls from br_cfm_frame_rx()<br /> are silently rejected.<br /> <br /> The cc_peer_disable() helper retains cancel_delayed_work_sync()<br /> because it is also used for the CC enable/disable toggle path where<br /> the work must remain re-schedulable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Give up GC if MSG_PEEK intervened.<br /> <br /> Igor Ushakov reported that GC purged the receive queue of<br /> an alive socket due to a race with MSG_PEEK with a nice repro.<br /> <br /> This is the exact same issue previously fixed by commit<br /> cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK").<br /> <br /> After GC was replaced with the current algorithm, the cited<br /> commit removed the locking dance in unix_peek_fds() and<br /> reintroduced the same issue.<br /> <br /> The problem is that MSG_PEEK bumps a file refcount without<br /> interacting with GC.<br /> <br /> Consider an SCC containing sk-A and sk-B, where sk-A is<br /> close()d but can be recv()ed via sk-B.<br /> <br /> The bad thing happens if sk-A is recv()ed with MSG_PEEK from<br /> sk-B and sk-B is close()d while GC is checking unix_vertex_dead()<br /> for sk-A and sk-B.<br /> <br /> GC thread User thread<br /> --------- -----------<br /> unix_vertex_dead(sk-A)<br /> -&gt; true sk-A&amp;#39;s file refcount : 1 -&gt; 2<br /> <br /> close(sk-B)<br /> -&gt; sk-B&amp;#39;s file refcount : 2 -&gt; 1<br /> unix_vertex_dead(sk-B)<br /> -&gt; true<br /> <br /> Initially, sk-A&amp;#39;s file refcount is 1 by the inflight fd in sk-B<br /> recvq. GC thinks sk-A is dead because the file refcount is the<br /> same as the number of its inflight fds.<br /> <br /> However, sk-A&amp;#39;s file refcount is bumped silently by MSG_PEEK,<br /> which invalidates the previous evaluation.<br /> <br /> At this moment, sk-B&amp;#39;s file refcount is 2; one by the open fd,<br /> and one by the inflight fd in sk-A. The subsequent close()<br /> releases one refcount by the former.<br /> <br /> Finally, GC incorrectly concludes that both sk-A and sk-B are dead.<br /> <br /> One option is to restore the locking dance in unix_peek_fds(),<br /> but we can resolve this more elegantly thanks to the new algorithm.<br /> <br /> The point is that the issue does not occur without the subsequent<br /> close() and we actually do not need to synchronise MSG_PEEK with<br /> the dead SCC detection.<br /> <br /> When the issue occurs, close() and GC touch the same file refcount.<br /> If GC sees the refcount being decremented by close(), it can just<br /> give up garbage-collecting the SCC.<br /> <br /> Therefore, we only need to signal the race during MSG_PEEK with<br /> a proper memory barrier to make it visible to the GC.<br /> <br /> Let&amp;#39;s use seqcount_t to notify GC when MSG_PEEK occurs and let<br /> it defer the SCC to the next run.<br /> <br /> This way no locking is needed on the MSG_PEEK side, and we can<br /> avoid imposing a penalty on every MSG_PEEK unnecessarily.<br /> <br /> Note that we can retry within unix_scc_dead() if MSG_PEEK is<br /> detected, but we do not do so to avoid hung task splat from<br /> abusive MSG_PEEK calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ<br /> <br /> Currently the code attempts to accept requests regardless of the<br /> command identifier which may cause multiple requests to be marked<br /> as pending (FLAG_DEFER_SETUP) which can cause more than<br /> L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer<br /> causing an overflow.<br /> <br /> The spec is quite clear that the same identifier shall not be used on<br /> subsequent requests:<br /> <br /> &amp;#39;Within each signaling channel a different Identifier shall be used<br /> for each successive request or indication.&amp;#39;<br /> https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d<br /> <br /> So this attempts to check if there are any channels pending with the<br /> same identifier and rejects if any are found.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/privcmd: restrict usage in unprivileged domU<br /> <br /> The Xen privcmd driver allows to issue arbitrary hypercalls from<br /> user space processes. This is normally no problem, as access is<br /> usually limited to root and the hypervisor will deny any hypercalls<br /> affecting other domains.<br /> <br /> In case the guest is booted using secure boot, however, the privcmd<br /> driver would be enabling a root user process to modify e.g. kernel<br /> memory contents, thus breaking the secure boot feature.<br /> <br /> The only known case where an unprivileged domU is really needing to<br /> use the privcmd driver is the case when it is acting as the device<br /> model for another guest. In this case all hypercalls issued via the<br /> privcmd driver will target that other guest.<br /> <br /> Fortunately the privcmd driver can already be locked down to allow<br /> only hypercalls targeting a specific domain, but this mode can be<br /> activated from user land only today.<br /> <br /> The target domain can be obtained from Xenstore, so when not running<br /> in dom0 restrict the privcmd driver to that target domain from the<br /> beginning, resolving the potential problem of breaking secure boot.<br /> <br /> This is XSA-482<br /> <br /> ---<br /> V2:<br /> - defer reading from Xenstore if Xenstore isn&amp;#39;t ready yet (Jan Beulich)<br /> - wait in open() if target domain isn&amp;#39;t known yet<br /> - issue message in case no target domain found (Jan Beulich)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: cirrus: cs42l43: Fix double-put in cs42l43_pin_probe()<br /> <br /> devm_add_action_or_reset() already invokes the action on failure,<br /> so the explicit put causes a double-put.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Squashfs: check metadata block offset is within range<br /> <br /> Syzkaller reports a "general protection fault in squashfs_copy_data"<br /> <br /> This is ultimately caused by a corrupted index look-up table, which<br /> produces a negative metadata block offset.<br /> <br /> This is subsequently passed to squashfs_copy_data (via<br /> squashfs_read_metadata) where the negative offset causes an out of bounds<br /> access.<br /> <br /> The fix is to check that the offset is within range in<br /> squashfs_read_metadata. This will trap this and other cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix memory leak in ice_set_ringparam()<br /> <br /> In ice_set_ringparam, tx_rings and xdp_rings are allocated before<br /> rx_rings. If the allocation of rx_rings fails, the code jumps to<br /> the done label leaking both tx_rings and xdp_rings. Furthermore, if<br /> the setup of an individual Rx ring fails during the loop, the code jumps<br /> to the free_tx label which releases tx_rings but leaks xdp_rings.<br /> <br /> Fix this by introducing a free_xdp label and updating the error paths to<br /> ensure both xdp_rings and tx_rings are properly freed if rx_rings<br /> allocation or setup fails.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow<br /> <br /> The dma_map_sg tracepoint can trigger a perf buffer overflow when<br /> tracing large scatter-gather lists. With devices like virtio-gpu<br /> creating large DRM buffers, nents can exceed 1000 entries, resulting<br /> in:<br /> <br /> phys_addrs: 1000 * 8 bytes = 8,000 bytes<br /> dma_addrs: 1000 * 8 bytes = 8,000 bytes<br /> lengths: 1000 * 4 bytes = 4,000 bytes<br /> Total: ~20,000 bytes<br /> <br /> This exceeds PERF_MAX_TRACE_SIZE (8192 bytes), causing:<br /> <br /> WARNING: CPU: 0 PID: 5497 at kernel/trace/trace_event_perf.c:405<br /> perf buffer not large enough, wanted 24620, have 8192<br /> <br /> Cap all three dynamic arrays at 128 entries using min() in the array<br /> size calculation. This ensures arrays are only as large as needed<br /> (up to the cap), avoiding unnecessary memory allocation for small<br /> operations while preventing overflow for large ones.<br /> <br /> The tracepoint now records the full nents/ents counts and a truncated<br /> flag so users can see when data has been capped.<br /> <br /> Changes in v2:<br /> - Use min(nents, DMA_TRACE_MAX_ENTRIES) for dynamic array sizing<br /> instead of fixed DMA_TRACE_MAX_ENTRIES allocation (feedback from<br /> Steven Rostedt)<br /> - This allocates only what&amp;#39;s needed up to the cap, avoiding waste<br /> for small operations<br /> <br /> Reviwed-by: Sean Anderson

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xt_CT: drop pending enqueued packets on template removal<br /> <br /> Templates refer to objects that can go away while packets are sitting in<br /> nfqueue refer to:<br /> <br /> - helper, this can be an issue on module removal.<br /> - timeout policy, nfnetlink_cttimeout might remove it.<br /> <br /> The use of templates with zone and event cache filter are safe, since<br /> this just copies values.<br /> <br /> Flush these enqueued packets in case the template rule gets removed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: release flowtable after rcu grace period on error<br /> <br /> Call synchronize_rcu() after unregistering the hooks from error path,<br /> since a hook that already refers to this flowtable can be already<br /> registered, exposing this flowtable to packet path and nfnetlink_hook<br /> control plane.<br /> <br /> This error path is rare, it should only happen by reaching the maximum<br /> number hooks or by failing to set up to hardware offload, just call<br /> synchronize_rcu().<br /> <br /> There is a check for already used device hooks by different flowtable<br /> that could result in EEXIST at this late stage. The hook parser can be<br /> updated to perform this check earlier to this error path really becomes<br /> rarely exercised.<br /> <br /> Uncovered by KASAN reported as use-after-free from nfnetlink_hook path<br /> when dumping hooks.