ESB-2026.4649

=========================================================================== AUSCERT External Security Bulletin Redistribution ESB-2026.4649 JSA108886 : On Demand: JSA Series: Multiple vulnerabilities resolved in Juniper Secure Analytics in 7.5.0 UP15 IF01 6 May 2026 =========================================================================== AUSCERT Security Bulletin Summary --------------------------------- Product: Juniper Secure Analytics (JSA) Publisher: Juniper Networks Operating System: Juniper Resolution: Patch/Upgrade CVE Names: CVE-2025-39971 CVE-2025-65018 CVE-2025-39697 CVE-2025-64720 CVE-2025-66293 CVE-2025-69419 CVE-2025-38129 CVE-2025-9086 CVE-2025-11083 CVE-2026-23097 CVE-2025-68800 CVE-2026-23001 CVE-2025-40064 CVE-2025-71085 CVE-2025-38248 CVE-2025-12818 CVE-2026-23074 Original Bulletin: https://supportportal.juniper.net/s/article/On-Demand-JSA-Series-Multiple-vulnerabilities-resolved-in-Juniper-Secure-Analytics-in-7-5-0-UP15-IF01 Comment: CVSS (Max): 7.8 CVE-2026-23074 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) CVSS Source: Juniper Networks Calculator: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS (Max): 0.1% (24th) CVE-2025-66293 2026-05-05 - --------------------------BEGIN INCLUDED TEXT-------------------- Article ID: JSA108886 Product Affected: These issues affect Juniper Secure Analytics 7.5.0. Severity Level: High CVSS Score: CVSS: v3.1: 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Problem: Multiple vulnerabilities have been resolved in 7.5.0 UP15 IF01. These issues affect Juniper Networks Juniper Secure Analytics: o from 7.5.0 before 7.5.0 UP15 IF01. Important security issues resolved include: +--------------+--------+-----------------------------------------------------+ | CVE | CVSS | Summary | +--------------+--------+-----------------------------------------------------+ | | |A vulnerability has been found in GNU Binutils 2.45. | | |7.8 ( |The affected element is the function elf_swap_shdr in| | |CVSS:3.1|the library bfd/elfcode.h of the component Linker. | | |/AV:L/ |The manipulation leads to heap-based buffer overflow.| |CVE-2025-11083|AC:L/ |The attack must be carried out locally. The exploit | | |PR:L/ |has been disclosed to the public and may be used. The| | |UI:N/S:U|identifier of the patch is | | |/C:H/I:H|9ca499644a21ceb3f946d1c179c38a83be084490. To fix this| | |/A:H ) |issue, it is recommended to deploy a patch. The code | | | |maintainer replied with "[f]ixed for 2.46". | +--------------+--------+-----------------------------------------------------+ | | |In the Linux kernel, the following vulnerability has | | | |been resolved: NFS: Fix a race when updating an | | |4.7 ( |existing write After nfs_lock_and_join_requests() | | |CVSS:3.1|tests for whether the request is still attached to | | |/AV:L/ |the mapping, nothing prevents a call to | | |AC:H/ |nfs_inode_remove_request() from succeeding until we | |CVE-2025-39697|PR:L/ |actually lock the page group. The reason is that | | |UI:N/S:U|whoever called nfs_inode_remove_request() doesn't | | |/C:N/I:N|necessarily have a lock on the page group head. So in| | |/A:H ) |order to avoid races, let's take the page group lock | | | |earlier in nfs_lock_and_join_requests(), and hold it | | | |across the removal of the request in | | | |nfs_inode_remove_request(). | +--------------+--------+-----------------------------------------------------+ | | |In the Linux kernel, the following vulnerability has | | | |been resolved: i40e: fix idx validation in config | |CVE-2025-39971| |queues msg Ensure idx is within range of active/ | | | |initialized TCs when iterating over vf->ch[idx] in | | | |i40e_vc_config_queues_msg(). | +--------------+--------+-----------------------------------------------------+ | | |LIBPNG is a reference library for use in applications| | | |that read, create, and manipulate PNG (Portable | | |7.1 ( |Network Graphics) raster image files. From version | | |CVSS:3.1|1.6.0 to before 1.6.51, an out-of-bounds read | | |/AV:N/ |vulnerability exists in png_image_read_composite when| |CVE-2025-64720|AC:L/ |processing palette images with | | |PR:N/ |PNG_FLAG_OPTIMIZE_ALPHA enabled. The palette | | |UI:R/S:U|compositing code in png_init_read_transformations | | |/C:L/I:N|incorrectly applies background compositing during | | |/A:H ) |premultiplication, violating the invariant component | | | |<= alpha x 257 required by the simplified PNG API. | | | |This issue has been patched in version 1.6.51. | +--------------+--------+-----------------------------------------------------+ | | |LIBPNG is a reference library for use in applications| | |7.1 ( |that read, create, and manipulate PNG (Portable | | |CVSS:3.1|Network Graphics) raster image files. From version | | |/AV:L/ |1.6.0 to before 1.6.51, there is a heap buffer | |CVE-2025-65018|AC:L/ |overflow vulnerability in the libpng simplified API | | |PR:N/ |function png_image_finish_read when processing 16-bit| | |UI:R/S:U|interlaced PNGs with 8-bit output format. | | |/C:N/I:H|Attacker-crafted interlaced PNG files cause heap | | |/A:H ) |writes beyond allocated buffer bounds. This issue has| | | |been patched in version 1.6.51. | +--------------+--------+-----------------------------------------------------+ | | |LIBPNG is a reference library for use in applications| | |7.1 ( |that read, create, and manipulate PNG (Portable | | |CVSS:3.1|Network Graphics) raster image files. Prior to | | |/AV:N/ |1.6.52, an out-of-bounds read vulnerability in | | |AC:L/ |libpng's simplified API allows reading up to 1012 | |CVE-2025-66293|PR:N/ |bytes beyond the png_sRGB_base[512] array when | | |UI:R/S:U|processing valid palette PNG images with partial | | |/C:L/I:N|transparency and gamma correction. The PNG files that| | |/A:H ) |trigger this vulnerability are valid per the PNG | | | |specification; the bug is in libpng's internal state | | | |management. Upgrade to libpng 1.6.52 or later. | +--------------+--------+-----------------------------------------------------+ | | |1. A cookie is set using the `secure` keyword for ` | | | |https://target ` 2. curl is redirected to or | | | |otherwise made to speak with ` http://target ` (same | | | |hostname, but using clear text HTTP) using the same | | | |cookie set 3. The same cookie name is set - but with | | |7.5 ( |just a slash as path (`path=\"/\",`). Since this site| | |CVSS:3.1|is not secure, the cookie *should* just be ignored. | | |/AV:N/ |4. A bug in the path comparison logic makes curl read| | |AC:L/ |outside a heap buffer boundary The bug either causes | |CVE-2025-9086 |PR:N/ |a crash or it potentially makes the comparison come | | |UI:N/S:U|to the wrong conclusion and lets the clear-text site | | |/C:N/I:N|override the contents of the secure cookie, contrary | | |/A:H ) |to expectations and depending on the memory contents | | | |immediately following the single-byte allocation that| | | |holds the path. The presumed and correct behavior | | | |would be to plainly ignore the second set of the | | | |cookie since it was already set as secure on a secure| | | |host so overriding it on an insecure host should not | | | |be okay. | +--------------+--------+-----------------------------------------------------+ | |5.9 ( |Integer wraparound in multiple PostgreSQL libpq | | |CVSS:3.1|client library functions allows an application input | | |/AV:N/ |provider or network peer to cause libpq to undersize | |CVE-2025-12818|AC:H/ |an allocation and write out-of-bounds by hundreds of | | |PR:N/ |megabytes. This results in a segmentation fault for | | |UI:N/S:U|the application using libpq. Versions before | | |/C:N/I:N|PostgreSQL 18.1, 17.7, 16.11, 15.15, 14.20, and 13.23| | |/A:H ) |are affected. | +--------------+--------+-----------------------------------------------------+ | | |In the Linux kernel, the following vulnerability has | | | |been resolved: page_pool: Fix use-after-free in | | | |page_pool_recycle_in_ring syzbot reported a uaf in | | | |page_pool_recycle_in_ring: BUG: KASAN: | | | |slab-use-after-free in lock_release+0x151/0xa30 | | | |kernel/locking/lockdep.c:5862 Read of size 8 at addr | | | |ffff8880286045a0 by task syz.0.284/6943 CPU: 0 UID: 0| | | |PID: 6943 Comm: syz.0.284 Not tainted | | | |6.13.0-rc3-syzkaller-gdfa94ce54f41 #0 Hardware name: | | | |Google Google Compute Engine/Google Compute Engine, | | | |BIOS Google 09/13/2024 Call Trace: <TASK> | | | |__dump_stack lib/dump_stack.c:94 [inline] | | | |dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 | | | |print_address_description mm/kasan/report.c:378 | | | |[inline] print_report+0x169/0x550 mm/kasan/ | | | |report.c:489 kasan_report+0x143/0x180 mm/kasan/ | | | |report.c:602 lock_release+0x151/0xa30 kernel/locking/| | | |lockdep.c:5862 __raw_spin_unlock_bh include/linux/ | | | |spinlock_api_smp.h:165 [inline] | | | |_raw_spin_unlock_bh+0x1b/0x40 kernel/locking/ | | | |spinlock.c:210 spin_unlock_bh include/linux/ | | | |spinlock.h:396 [inline] ptr_ring_produce_bh include/ | | | |linux/ptr_ring.h:164 [inline] | | |7.8 ( |page_pool_recycle_in_ring net/core/page_pool.c:707 | | |CVSS:3.1|[inline] page_pool_put_unrefed_netmem+0x748/0xb00 net| | |/AV:L/ |/core/page_pool.c:826 page_pool_put_netmem include/ | | |AC:L/ |net/page_pool/helpers.h:323 [inline] | |CVE-2025-38129|PR:L/ |page_pool_put_full_netmem include/net/page_pool/ | | |UI:N/S:U|helpers.h:353 [inline] napi_pp_put_page+0x149/0x2b0 | | |/C:H/I:H|net/core/skbuff.c:1036 skb_pp_recycle net/core/ | | |/A:H ) |skbuff.c:1047 [inline] skb_free_head net/core/ | | | |skbuff.c:1094 [inline] skb_release_data+0x6c4/0x8a0 | | | |net/core/skbuff.c:1125 skb_release_all net/core/ | | | |skbuff.c:1190 [inline] __kfree_skb net/core/ | | | |skbuff.c:1204 [inline] sk_skb_reason_drop+0x1c9/0x380| | | |net/core/skbuff.c:1242 kfree_skb_reason include/linux| | | |/skbuff.h:1263 [inline] __skb_queue_purge_reason | | | |include/linux/skbuff.h:3343 [inline] root cause is: | | | |page_pool_recycle_in_ring ptr_ring_produce spin_lock | | | |(&r->producer_lock); WRITE_ONCE(r->queue[r-> | | | |producer++], ptr) //recycle last page to pool | | | |page_pool_release page_pool_scrub | | | |page_pool_empty_ring ptr_ring_consume | | | |page_pool_return_page //release all page | | | |__page_pool_destroy free_percpu(pool->recycle_stats);| | | |free(pool) //free spin_unlock(&r->producer_lock); // | | | |pool->ring uaf read recycle_stat_inc(pool, ring); | | | |page_pool can be free while page pool recycle the | | | |last page in ring. Add producer-lock barrier to | | | |page_pool_release to prevent the page pool from being| | | |free before all pages have been recycled. | | | |recycle_stat_inc() is empty when | | | |CONFIG_PAGE_POOL_STATS is not enabled, which will | | | |trigger Wempty-body build warning. Add definition for| | | |pool stat macro to fix warning. | +--------------+--------+-----------------------------------------------------+ | | |In the Linux kernel, the following vulnerability has | | | |been resolved: bridge: mcast: Fix use-after-free | | | |during router port configuration The bridge maintains| | | |a global list of ports behind which a multicast | | | |router resides. The list is consulted during | | | |forwarding to ensure multicast packets are forwarded | | | |to these ports even if the ports are not member in | | | |the matching MDB entry. When per-VLAN multicast | | | |snooping is enabled, the per-port multicast context | | | |is disabled on each port and the port is removed from| | | |the global router port list: # ip link add name br1 | | | |up type bridge vlan_filtering 1 mcast_snooping 1 # ip| | | |link add name dummy1 up master br1 type dummy # ip | | | |link set dev dummy1 type bridge_slave mcast_router 2 | | | |$ bridge -d mdb show | grep router router ports on | | | |br1: dummy1 # ip link set dev br1 type bridge | | | |mcast_vlan_snooping 1 $ bridge -d mdb show | grep | | | |router However, the port can be re-added to the | | | |global list even when per-VLAN multicast snooping is | | | |enabled: # ip link set dev dummy1 type bridge_slave | | | |mcast_router 0 # ip link set dev dummy1 type | | | |bridge_slave mcast_router 2 $ bridge -d mdb show | | | | |grep router router ports on br1: dummy1 Since commit | | | |4b30ae9adb04 ("net: bridge: mcast: re-implement | | | |br_multicast_{enable, disable}_port functions"), when| | | |per-VLAN multicast snooping is enabled, multicast | | | |disablement on a port will disable the per-{port, | | | |VLAN} multicast contexts and not the per-port one. As| | | |a result, a port will remain in the global router | | | |port list even after it is deleted. This will lead to| | | |a use-after-free [1] when the list is traversed (when| | | |adding a new port to the list, for example): # ip | | | |link del dev dummy1 # ip link add name dummy2 up | | | |master br1 type dummy # ip link set dev dummy2 type | | | |bridge_slave mcast_router 2 Similarly, stale entries | | |7.8 ( |can also be found in the per-VLAN router port list. | | |CVSS:3.1|When per-VLAN multicast snooping is disabled, the | | |/AV:L/ |per-{port, VLAN} contexts are disabled on each port | |CVE-2025-38248|AC:L/ |and the port is removed from the per-VLAN router port| | |PR:L/ |list: # ip link add name br1 up type bridge | | |UI:N/S:U|vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping| | |/C:H/I:H|1 # ip link add name dummy1 up master br1 type dummy | | |/A:H ) |# bridge vlan add vid 2 dev dummy1 # bridge vlan | | | |global set vid 2 dev br1 mcast_snooping 1 # bridge | | | |vlan set vid 2 dev dummy1 mcast_router 2 $ bridge | | | |vlan global show dev br1 vid 2 | grep router router | | | |ports: dummy1 # ip link set dev br1 type bridge | | | |mcast_vlan_snooping 0 $ bridge vlan global show dev | | | |br1 vid 2 | grep router However, the port can be | | | |re-added to the per-VLAN list even when per-VLAN | | | |multicast snooping is disabled: # bridge vlan set vid| | | |2 dev dummy1 mcast_router 0 # bridge vlan set vid 2 | | | |dev dummy1 mcast_router 2 $ bridge vlan global show | | | |dev br1 vid 2 | grep router router ports: dummy1 When| | | |the VLAN is deleted from the port, the per-{port, | | | |VLAN} multicast context will not be disabled since | | | |multicast snooping is not enabled on the VLAN. As a | | | |result, the port will remain in the per-VLAN router | | | |port list even after it is no longer member in the | | | |VLAN. This will lead to a use-after-free [2] when the| | | |list is traversed (when adding a new port to the | | | |list, for example): # ip link add name dummy2 up | | | |master br1 type dummy # bridge vlan add vid 2 dev | | | |dummy2 # bridge vlan del vid 2 dev dummy1 # bridge | | | |vlan set vid 2 dev dummy2 mcast_router 2 Fix these | | | |issues by removing the port from the relevant (global| | | |or per-VLAN) router port list in | | | |br_multicast_port_ctx_deinit(). The function is | | | |invoked during port deletion with the per-port | | | |multicast context and during VLAN deletion with the | | | |per-{port, VLAN} multicast context. Note that | | | |deleting the multicast router timer is not enough as | | | |it only takes care of the temporary multicast router | | | |states (1 or 3) and not the permanent one (2). [1] | | | |BUG: KASAN: slab-out-of-bounds in | | | |br_multicast_add_router.part.0+0x3f1/0x560 Write of | | | |size 8 at addr ffff888004a67328 by task ip/384 [...] | | | |Call Trace: <TASK> dump_stack ---truncated--- | +--------------+--------+-----------------------------------------------------+ | | |In the Linux kernel, the following vulnerability has | | | |been resolved: smc: Fix use-after-free in | | | |__pnet_find_base_ndev(). syzbot reported | | | |use-after-free of net_device in __pnet_find_base_ndev| | | |(), which was called during connect(). [0] | | | |smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->| | | |dev and passes down to pnet_find_base_ndev(), where | | | |RTNL is held. Then, UAF happened at | | | |__pnet_find_base_ndev() when the dev is first used. | | | |This means dev had already been freed before | | | |acquiring RTNL in pnet_find_base_ndev(). While dev is| | | |going away, dst->dev could be swapped with | | | |blackhole_netdev, and the dev's refcnt by dst will be| | | |released. We must hold dev's refcnt before calling | | | |smc_pnet_find_ism_resource(). Also, | | | |smc_pnet_find_roce_resource() has the same problem. | | | |Let's use __sk_dst_get() and dst_dev_rcu() in the two| | | |functions. [0]: BUG: KASAN: use-after-free in | | | |__pnet_find_base_ndev+0x1b1/0x1c0 net/smc/ | | | |smc_pnet.c:926 Read of size 1 at addr | | | |ffff888036bac33a by task syz.0.3632/18609 CPU: 1 UID:| | | |0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #| | | |0 PREEMPT(full) Hardware name: Google Google Compute | | | |Engine/Google Compute Engine, BIOS Google 08/18/2025 | | | |Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/ | | | |dump_stack.c:120 print_address_description mm/kasan/ | | | |report.c:378 [inline] print_report+0xca/0x240 mm/ | | | |kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/| | | |report.c:595 __pnet_find_base_ndev+0x1b1/0x1c0 net/ | | | |smc/smc_pnet.c:926 pnet_find_base_ndev net/smc/ | | | |smc_pnet.c:946 [inline] smc_pnet_find_ism_by_pnetid | | | |net/smc/smc_pnet.c:1103 [inline] | | | |smc_pnet_find_ism_resource+0xef/0x390 net/smc/ | | | |smc_pnet.c:1154 smc_find_ism_device net/smc/ | | | |af_smc.c:1030 [inline] smc_find_proposal_devices net/| | | |smc/af_smc.c:1115 [inline] __smc_connect+0x372/0x1890| | | |net/smc/af_smc.c:1545 smc_connect+0x877/0xd90 net/smc| | | |/af_smc.c:1715 __sys_connect_file net/socket.c:2086 | | | |[inline] __sys_connect+0x313/0x440 net/socket.c:2105 | | | |__do_sys_connect net/socket.c:2111 [inline] | | | |__se_sys_connect net/socket.c:2108 [inline] | |CVE-2025-40064| |__x64_sys_connect+0x7a/0x90 net/socket.c:2108 | | | |do_syscall_x64 arch/x86/entry/syscall_64.c:63 | | | |[inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/ | | | |syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/ | | | |0x7f RIP: 0033:0x7f47cbf8eba9 Code: ff ff c3 66 2e 0f| | | |1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48| | | |89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05| | | |<48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 | | | |d8 64 89 01 48 RSP: 002b:00007f47ccdb1038 EFLAGS: | | | |00000246 ORIG_RAX: 000000000000002a RAX: | | | |ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: | | | |00007f47cbf8eba9 RDX: 0000000000000010 RSI: | | | |0000200000000280 RDI: 000000000000000b RBP: | | | |00007f47cc011e19 R08: 0000000000000000 R09: | | | |0000000000000000 R10: 0000000000000000 R11: | | | |0000000000000246 R12: 0000000000000000 R13: | | | |00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: | | | |00007ffc512f8aa8 </TASK> The buggy address belongs to| | | |the physical page: page: refcount:0 mapcount:0 | | | |mapping:0000000000000000 index:0xffff888036bacd00 | | | |pfn:0x36bac flags: 0xfff00000000000(node=0|zone=1| | | | |lastcpupid=0x7ff) raw: 00fff00000000000 | | | |ffffea0001243d08 ffff8880b863fdc0 0000000000000000 | | | |raw: ffff888036bacd00 0000000000000000 | | | |00000000ffffffff 0000000000000000 page dumped | | | |because: kasan: bad access detected page_owner tracks| | | |the page as freed page last allocated via order 2, | | | |migratetype Unmovable, gfp_mask 0x446dc0 | | | |(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN| | | | |__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid | | | |16741 (syz-executor), ts 343313197788, free_ts | | | |380670750466 set_page_owner include/linux/ | | | |page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 | | | |mm/page_alloc.c:1851 prep_new_page mm/ | | | |page_alloc.c:1859 [inline] | | | |get_page_from_freelist+0x21e4/0x22c0 mm/ | | | |page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/ | | | |0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/ | | | |0x4a0 mm/mempolicy.c:2416 ___kmalloc_large_node+0x5f/| | | |0x1b0 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18| | | |/0x90 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364| | | |[inline] __kvmalloc_node ---truncated--- | +--------------+--------+-----------------------------------------------------+ | | |In the Linux kernel, the following vulnerability has | | | |been resolved: mlxsw: spectrum_mr: Fix use-after-free| | | |when updating multicast route stats Cited commit | | | |added a dedicated mutex (instead of RTNL) to protect | | | |the multicast route list, so that it will not change | | | |while the driver periodically traverses it in order | | | |to update the kernel about multicast route stats that| | | |were queried from the device. One instance of list | | | |entry deletion (during route replace) was missed and | | | |it can result in a use-after-free [1]. Fix by | | | |acquiring the mutex before deleting the entry from | | | |the list and releasing it afterwards. [1] BUG: KASAN:| | | |slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5| | | |/0x540 drivers/net/ethernet/mellanox/mlxsw/ | | | |spectrum_mr.c:1006 [mlxsw_spectrum] Read of size 8 at| | | |addr ffff8881523c2fa8 by task kworker/2:5/22043 CPU: | | | |2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted | | | |6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full) | | | |Hardware name: Mellanox Technologies Ltd. MSN2010/ | | | |SA002610, BIOS 5.6.5 08/24/2017 Workqueue: mlxsw_core| | | |mlxsw_sp_mr_stats_update [mlxsw_spectrum] Call Trace:| | | |<TASK> dump_stack_lvl+0xba/0x110 print_report+0x174/ | | | |0x4f5 kasan_report+0xdf/0x110 | | | |mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ | |CVE-2025-68800| |ethernet/mellanox/mlxsw/spectrum_mr.c:1006 | | | |[mlxsw_spectrum] process_one_work+0x9cc/0x18e0 | | | |worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 | | | |ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30| | | |</TASK> Allocated by task 29933: | | | |kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30| | | |__kasan_kmalloc+0x8f/0xa0 mlxsw_sp_mr_route_add+0xd8/| | | |0x4770 [mlxsw_spectrum] | | | |mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/| | | |net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 | | | |[mlxsw_spectrum] process_one_work+0x9cc/0x18e0 | | | |worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 | | | |ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30| | | |Freed by task 29933: kasan_save_stack+0x30/0x50 | | | |kasan_save_track+0x14/0x30 | | | |__kasan_save_free_info+0x3b/0x70 | | | |__kasan_slab_free+0x43/0x70 kfree+0x14e/0x700 | | | |mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ | | | |ethernet/mellanox/mlxsw/spectrum_mr.c:444 | | | |[mlxsw_spectrum] | | | |mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/| | | |net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 | | | |[mlxsw_spectrum] process_one_work+0x9cc/0x18e0 | | | |worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 | | | |ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30| +--------------+--------+-----------------------------------------------------+ | | |Issue summary: Calling PKCS12_get_friendlyname() | | | |function on a maliciously crafted PKCS#12 file with a| | | |BMPString (UTF-16BE) friendly name containing | | | |non-ASCII BMP code point can trigger a one byte write| | | |before the allocated buffer. Impact summary: The | | | |out-of-bounds write can cause a memory corruption | | | |which can have various consequences including a | | | |Denial of Service. The OPENSSL_uni2utf8() function | | | |performs a two-pass conversion of a PKCS#12 BMPString| | | |(UTF-16BE) to UTF-8. In the second pass, when | | | |emitting UTF-8 bytes, the helper function bmp_to_utf8| | | |() incorrectly forwards the remaining UTF-16 source | | | |byte count as the destination buffer capacity to | | | |UTF8_putc(). For BMP code points above U+07FF, UTF-8 | | |7.4 ( |requires three bytes, but the forwarded capacity can | | |CVSS:3.1|be just two bytes. UTF8_putc() then returns -1, and | | |/AV:N/ |this negative value is added to the output length | | |AC:H/ |without validation, causing the length to become | |CVE-2025-69419|PR:N/ |negative. The subsequent trailing NUL byte is then | | |UI:N/S:U|written at a negative offset, causing write outside | | |/C:H/I:H|of heap allocated buffer. The vulnerability is | | |/A:N ) |reachable via the public PKCS12_get_friendlyname() | | | |API when parsing attacker-controlled PKCS#12 files. | | | |While PKCS12_parse() uses a different code path that | | | |avoids this issue, PKCS12_get_friendlyname() directly| | | |invokes the vulnerable function. Exploitation | | | |requires an attacker to provide a malicious PKCS#12 | | | |file to be parsed by the application and the attacker| | | |can just trigger a one zero byte write before the | | | |allocated buffer. For that reason the issue was | | | |assessed as Low severity according to our Security | | | |Policy. The FIPS modules in 3.6, 3.5, 3.4, 3.3 and | | | |3.0 are not affected by this issue, as the PKCS#12 | | | |implementation is outside the OpenSSL FIPS module | | | |boundary. OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 | | | |are vulnerable to this issue. OpenSSL 1.0.2 is not | | | |affected by this issue. | +--------------+--------+-----------------------------------------------------+ | | |In the Linux kernel, the following vulnerability has | | | |been resolved: ipv6: BUG() in pskb_expand_head() as | | | |part of calipso_skbuff_setattr() There exists a | | | |kernel oops caused by a BUG_ON(nhead < 0) at net/core| | | |/skbuff.c:2232 in pskb_expand_head(). This bug is | | | |triggered as part of the calipso_skbuff_setattr() | | | |routine when skb_cow() is passed headroom > INT_MAX | | | |(i.e. (int)(skb_headroom(skb) + len_delta) < 0). The | | | |root cause of the bug is due to an implicit integer | | | |cast in __skb_cow(). The check (headroom > | | | |skb_headroom(skb)) is meant to ensure that delta = | | | |headroom - skb_headroom(skb) is never negative, | | | |otherwise we will trigger a BUG_ON in | | | |pskb_expand_head(). However, if headroom > INT_MAX | | | |and delta <= -NET_SKB_PAD, the check passes, delta | | | |becomes negative, and pskb_expand_head() is passed a | | | |negative value for nhead. Fix the trigger condition | | |5.5 ( |in calipso_skbuff_setattr(). Avoid passing "negative"| | |CVSS:3.1|headroom sizes to skb_cow() within | | |/AV:L/ |calipso_skbuff_setattr() by only using skb_cow() to | |CVE-2025-71085|AC:L/ |grow headroom. PoC: Using `netlabelctl` tool: | | |PR:L/ |netlabelctl map del default netlabelctl calipso add | | |UI:N/S:U|pass doi:7 netlabelctl map add default address:0::1/ | | |/C:N/I:N|128 protocol:calipso,7 Then run the following PoC: | | |/A:H ) |int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); /| | | |/ setup msghdr int cmsg_size = 2; int cmsg_len = | | | |0x60; struct msghdr msg; struct sockaddr_in6 | | | |dest_addr; struct cmsghdr * cmsg = (struct cmsghdr *)| | | |calloc(1, sizeof(struct cmsghdr) + cmsg_len); | | | |msg.msg_name = &dest_addr; msg.msg_namelen = sizeof | | | |(dest_addr); msg.msg_iov = NULL; msg.msg_iovlen = 0; | | | |msg.msg_control = cmsg; msg.msg_controllen = | | | |cmsg_len; msg.msg_flags = 0; // setup sockaddr | | | |dest_addr.sin6_family = AF_INET6; dest_addr.sin6_port| | | |= htons(31337); dest_addr.sin6_flowinfo = htonl | | | |(31337); dest_addr.sin6_addr = in6addr_loopback; | | | |dest_addr.sin6_scope_id = 31337; // setup cmsghdr | | | |cmsg->cmsg_len = cmsg_len; cmsg->cmsg_level = | | | |IPPROTO_IPV6; cmsg->cmsg_type = IPV6_HOPOPTS; char * | | | |hop_hdr = (char *)cmsg + sizeof(struct cmsghdr); | | | |hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80| | | |sendmsg(fd, &msg, 0); | +--------------+--------+-----------------------------------------------------+ | | |In the Linux kernel, the following vulnerability has | | | |been resolved: macvlan: fix possible UAF in | | |7.8 ( |macvlan_forward_source() Add RCU protection on | | |CVSS:3.1|(struct macvlan_source_entry)->vlan. Whenever | | |/AV:L/ |macvlan_hash_del_source() is called, we must clear | |CVE-2026-23001|AC:L/ |entry->vlan pointer before RCU grace period starts. | | |PR:L/ |This allows macvlan_forward_source() to skip over | | |UI:N/S:U|entries queued for freeing. Note that macvlan_dev are| | |/C:H/I:H|already RCU protected, as they are embedded in a | | |/A:H ) |standard netdev (netdev_priv(ndev)). https: // | | | |lore.kernel.org/netdev/ | | | |695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u | +--------------+--------+-----------------------------------------------------+ | | |In the Linux kernel, the following vulnerability has | | | |been resolved: net/sched: Enforce that teql can only | | | |be used as root qdisc Design intent of teql is that | | | |it is only supposed to be used as root qdisc. We need| | | |to check for that constraint. Although not important,| | | |I will describe the scenario that unearthed this | | | |issue for the curious. GangMin Kim | | | |<km.kim1503@gmail.com> managed to concot a scenario | | | |as follows: ROOT qdisc 1:0 (QFQ) +-- class 1:1 | | | |(weight=15, lmax=16384) netem with delay 6.4s +-- | | |7.8 ( |class 1:2 (weight=1, lmax=1514) teql GangMin sends a | | |CVSS:3.1|packet which is enqueued to 1:1 (netem). Any | | |/AV:L/ |invocation of dequeue by QFQ from this class will not| | |AC:L/ |return a packet until after 6.4s. In the meantime, a | |CVE-2026-23074|PR:L/ |second packet is sent and it lands on 1:2. teql's | | |UI:N/S:U|enqueue will return success and this will activate | | |/C:H/I:H|class 1:2. Main issue is that teql only updates the | | |/A:H ) |parent visible qlen (sch->q.qlen) at dequeue. Since | | | |QFQ will only call dequeue if peek succeeds (and | | | |teql's peek always returns NULL), dequeue will never | | | |be called and thus the qlen will remain as 0. With | | | |that in mind, when GangMin updates 1:2's lmax value, | | | |the qfq_change_class calls qfq_deact_rm_from_agg. | | | |Since the child qdisc's qlen was not incremented, qfq| | | |fails to deactivate the class, but still frees its | | | |pointers from the aggregate. So when the first packet| | | |is rescheduled after 6.4 seconds (netem's delay), a | | | |dangling pointer is accessed causing GangMin's | | | |causing a UAF. | +--------------+--------+-----------------------------------------------------+ | | |In the Linux kernel, the following vulnerability has | | | |been resolved: migrate: correct lock ordering for | | | |hugetlb file folios Syzbot has found a deadlock | | | |(analyzed by Lance Yang): 1) Task (5749): Holds | | | |folio_lock, then tries to acquire i_mmap_rwsem(read | | | |lock). 2) Task (5754): Holds i_mmap_rwsem(write | | | |lock), then tries to acquire folio_lock. | | | |migrate_pages() -> migrate_hugetlbs() -> | | |5.5 ( |unmap_and_move_huge_page() <- Takes folio_lock! -> | | |CVSS:3.1|remove_migration_ptes() -> __rmap_walk_file() -> | | |/AV:L/ |i_mmap_lock_read() <- Waits for i_mmap_rwsem(read | | |AC:L/ |lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole | |CVE-2026-23097|PR:L/ |() <- Takes i_mmap_rwsem(write lock)! -> | | |UI:N/S:U|hugetlbfs_zero_partial_page() -> | | |/C:N/I:N|filemap_lock_hugetlb_folio() -> filemap_lock_folio() | | |/A:H ) |-> __filemap_get_folio <- Waits for folio_lock! The | | | |migration path is the one taking locks in the wrong | | | |order according to the documentation at the top of mm| | | |/rmap.c. So expand the scope of the existing | | | |i_mmap_lock to cover the calls to | | | |remove_migration_ptes() too. This is (mostly) how it | | | |used to be after commit c0d0381ade79. That was | | | |removed by 336bf30eb765 for both file & anon hugetlb | | | |pages when it should only have been removed for anon | | | |hugetlb pages. | +--------------+--------+-----------------------------------------------------+ Juniper SIRT is not aware of any malicious exploitation of these vulnerabilities. These issues were discovered by a third-party upstream provider. Solution: The following software releases have been updated to resolve these specific issues: Juniper Secure Analytics in 7.5.0 UP14 IF01 and all subsequent releases. Software updates are available for download at https://support.juniper.net/ support/downloads/ Note: Juniper SIRT's policy is not to evaluate releases that are beyond End of Engineering (EOE) or End of Life (EOL). Workaround: There are no known workarounds for these issues. Severity Assessment: Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories." Modification History: o 2026-05-05: Initial Publication Related Information: o KB16613: Overview of the Juniper Networks SIRT Quarterly Security Bulletin Publication Process o KB16765: In which releases are vulnerabilities fixed? o KB16446: Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories o Report a Security Vulnerability - How to Contact the Juniper Networks Security Incident Response Team o www.ibm.com/support/pages/node/7258234 o www.ibm.com/support/pages/node/7268179 Last Updated: 2026-05-05 Created: 2026-05-05 - --------------------------END INCLUDED TEXT---------------------- You have received this e-mail bulletin as a result of your organisation's registration with AUSCERT. The mailing list you are subscribed to is maintained within your organisation, so if you do not wish to continue receiving these bulletins you should contact your local IT manager. If you do not know who that is, please send an email to auscert@auscert.org.au and we will forward your request to the appropriate person. NOTE: Third Party Rights This security bulletin is provided as a service to AUSCERT's members. As AUSCERT did not write the document quoted above, AUSCERT has had no control over its content. The decision to follow or act on information or advice contained in this security bulletin is the responsibility of each user or organisation, and should be considered in accordance with your organisation's site policies and procedures. AUSCERT takes no responsibility for consequences which may arise from following or acting on information or advice contained in this security bulletin. NOTE: This is only the original release of the security bulletin. It may not be updated when updates to the original are made. If downloading at a later date, it is recommended that the bulletin is retrieved directly from the author's website to ensure that the information is still current. Contact information for the authors of the original document is included in the Security Bulletin above. If you have any questions or need further information, please contact them directly. Previous advisories and external security bulletins can be retrieved from: https://portal.auscert.org.au/bulletins/ =========================================================================== AUSCERT The University of Queensland, Brisbane QLD 4072 Australia e: auscert@auscert.org.au t: +61 (0)7 3365 4417 Allies in Cyber Security ===========================================================================