Vulnerabilities

An Improper Isolation or Compartmentalization vulnerability in the kernel of Juniper Networks Junos OS allows a local attacker with high privileges to compromise the integrity of the device.<br /> <br /> A local attacker with access to the shell is able to inject arbitrary code which can compromise an affected device.<br /> This issue is not exploitable from the Junos CLI.<br /> This issue affects Junos OS: <br /> <br /> <br /> <br /> * All versions before 21.2R3-S9,<br /> * 21.4 versions before 21.4R3-S10, <br /> * 22.2 versions before 22.2R3-S6, <br /> * 22.4 versions before 22.4R3-S6, <br /> * 23.2 versions before 23.2R2-S3, <br /> * 23.4 versions before 23.4R2-S4,<br /> * 24.2 versions before 24.2R1-S2, 24.2R2.

In JetBrains Ktor before 3.1.1 an HTTP Request Smuggling was possible

In JetBrains Runtime before 21.0.6b872.80 arbitrary dynamic library execution due to insecure macOS flags was possible

An integer underflow during deserialization may allow any unauthenticated user to read out of bounds heap memory. This may result into secret data or pointers revealing the layout of the address space to be included into a deserialized data structure, which may potentially lead to thread crashes or cause denial of service conditions.

A command injection vulnerability exists in the /check_image_and_trigger_recovery API endpoint of Bitdefender Box 1 (firmware version 1.3.11.490). This flaw allows an unauthenticated, network-adjacent attacker to execute arbitrary commands on the device, potentially leading to full remote code execution (RCE).

Bitdefender Box, versions 1.3.11.490 through 1.3.11.505, uses the insecure HTTP protocol to download assets over the Internet to update and restart daemons and detection rules on the devices. Updates can be remotely triggered through the /set_temp_token API method. Then, an unauthenticated and network-adjacent attacker can use man-in-the-middle (MITM) techniques to return malicious responses. Restarted daemons that use malicious assets can then be exploited for remote code execution on the device.

The ShopLentor – WooCommerce Builder for Elementor &amp; Gutenberg +20 Modules – All in One Solution (formerly WooLentor) plugin for WordPress is vulnerable to a Stored DOM-Based Cross-Site Scripting via the plugin&amp;#39;s Flash Sale Countdown module in all versions up to, and including, 3.1.0 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

An improper access control vulnerability exists in Bitdefender Box 1 (firmware version 1.3.52.928 and below) that allows an unauthenticated attacker to downgrade the device&amp;#39;s firmware to an older, potentially vulnerable version of a Bitdefender-signed firmware. The attack requires Bitdefender BOX to be booted in Recovery Mode and that the attacker be present within the WiFi range of the BOX unit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/migrate_device: don&amp;#39;t add folio to be freed to LRU in migrate_device_finalize()<br /> <br /> If migration succeeded, we called<br /> folio_migrate_flags()-&gt;mem_cgroup_migrate() to migrate the memcg from the<br /> old to the new folio. This will set memcg_data of the old folio to 0.<br /> <br /> Similarly, if migration failed, memcg_data of the dst folio is left unset.<br /> <br /> If we call folio_putback_lru() on such folios (memcg_data == 0), we will<br /> add the folio to be freed to the LRU, making memcg code unhappy. Running<br /> the hmm selftests:<br /> <br /> # ./hmm-tests<br /> ...<br /> # RUN hmm.hmm_device_private.migrate ...<br /> [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00<br /> [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff)<br /> [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9<br /> [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000<br /> [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg &amp;&amp; !mem_cgroup_disabled())<br /> [ 102.087230][T14893] ------------[ cut here ]------------<br /> [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170<br /> [ 102.090478][T14893] Modules linked in:<br /> [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151<br /> [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170<br /> [ 102.096104][T14893] Code: ...<br /> [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293<br /> [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426<br /> [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880<br /> [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000<br /> [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8<br /> [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000<br /> [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000<br /> [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0<br /> [ 102.113478][T14893] PKRU: 55555554<br /> [ 102.114172][T14893] Call Trace:<br /> [ 102.114805][T14893] <br /> [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170<br /> [ 102.116547][T14893] ? __warn.cold+0x110/0x210<br /> [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170<br /> [ 102.118667][T14893] ? report_bug+0x1b9/0x320<br /> [ 102.119571][T14893] ? handle_bug+0x54/0x90<br /> [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50<br /> [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0<br /> [ 102.123506][T14893] ? dump_page+0x4f/0x60<br /> [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170<br /> [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200<br /> [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10<br /> [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720<br /> [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10<br /> [ 102.129550][T14893] folio_putback_lru+0x16/0x80<br /> [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530<br /> [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0<br /> [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80<br /> <br /> Likely, nothing else goes wrong: putting the last folio reference will<br /> remove the folio from the LRU again. So besides memcg complaining, adding<br /> the folio to be freed to the LRU is just an unnecessary step.<br /> <br /> The new flow resembles what we have in migrate_folio_move(): add the dst<br /> to the lru, rem<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: prevent opcode speculation<br /> <br /> sqe-&gt;opcode is used for different tables, make sure we santitise it<br /> against speculations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC<br /> <br /> Erhard reported the following KASAN hit while booting his PowerMac G4<br /> with a KASAN-enabled kernel 6.13-rc6:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8<br /> Write of size 8 at addr f1000000 by task chronyd/1293<br /> <br /> CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2<br /> Tainted: [W]=WARN<br /> Hardware name: PowerMac3,6 7455 0x80010303 PowerMac<br /> Call Trace:<br /> [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable)<br /> [c24375b0] [c0504998] print_report+0xdc/0x504<br /> [c2437610] [c050475c] kasan_report+0xf8/0x108<br /> [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c<br /> [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8<br /> [c24376c0] [c004c014] patch_instructions+0x15c/0x16c<br /> [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c<br /> [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac<br /> [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec<br /> [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478<br /> [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14<br /> [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4<br /> [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890<br /> [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420<br /> [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c<br /> --- interrupt: c00 at 0x5a1274<br /> NIP: 005a1274 LR: 006a3b3c CTR: 005296c8<br /> REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4)<br /> MSR: 0200f932 CR: 24004422 XER: 00000000<br /> <br /> GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932<br /> GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57<br /> GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002<br /> GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001<br /> NIP [005a1274] 0x5a1274<br /> LR [006a3b3c] 0x6a3b3c<br /> --- interrupt: c00<br /> <br /> The buggy address belongs to the virtual mapping at<br /> [f1000000, f1002000) created by:<br /> text_area_cpu_up+0x20/0x190<br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30<br /> flags: 0x80000000(zone=2)<br /> raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001<br /> raw: 00000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ^<br /> f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ==================================================================<br /> <br /> f8 corresponds to KASAN_VMALLOC_INVALID which means the area is not<br /> initialised hence not supposed to be used yet.<br /> <br /> Powerpc text patching infrastructure allocates a virtual memory area<br /> using get_vm_area() and flags it as VM_ALLOC. But that flag is meant<br /> to be used for vmalloc() and vmalloc() allocated memory is not<br /> supposed to be used before a call to __vmalloc_node_range() which is<br /> never called for that area.<br /> <br /> That went undetected until commit e4137f08816b ("mm, kasan, kmsan:<br /> instrument copy_from/to_kernel_nofault")<br /> <br /> The area allocated by text_area_cpu_up() is not vmalloc memory, it is<br /> mapped directly on demand when needed by map_kernel_page(). There is<br /> no VM flag corresponding to such usage, so just pass no flag. That way<br /> the area will be unpoisonned and usable immediately.

Generation of Error Message Containing Sensitive Information vulnerability in Hillstone Networks Hillstone Next Generation FireWall.This issue affects Hillstone Next Generation FireWall: from 5.5R8P1 before 5.5R8P23.