Vulnerabilities

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 & 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'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'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.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drop_monitor: fix incorrect initialization order<br /> <br /> Syzkaller reports the following bug:<br /> <br /> BUG: spinlock bad magic on CPU#1, syz-executor.0/7995<br /> lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0<br /> CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1<br /> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x119/0x179 lib/dump_stack.c:118<br /> debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]<br /> do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline]<br /> _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159<br /> reset_per_cpu_data+0xe6/0x240 [drop_monitor]<br /> net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor]<br /> genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739<br /> genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]<br /> genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800<br /> netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497<br /> genl_rcv+0x29/0x40 net/netlink/genetlink.c:811<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]<br /> netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348<br /> netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916<br /> sock_sendmsg_nosec net/socket.c:651 [inline]<br /> __sock_sendmsg+0x157/0x190 net/socket.c:663<br /> ____sys_sendmsg+0x712/0x870 net/socket.c:2378<br /> ___sys_sendmsg+0xf8/0x170 net/socket.c:2432<br /> __sys_sendmsg+0xea/0x1b0 net/socket.c:2461<br /> do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x62/0xc7<br /> RIP: 0033:0x7f3f9815aee9<br /> 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 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9<br /> RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007<br /> RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768<br /> <br /> If drop_monitor is built as a kernel module, syzkaller may have time<br /> to send a netlink NET_DM_CMD_START message during the module loading.<br /> This will call the net_dm_monitor_start() function that uses<br /> a spinlock that has not yet been initialized.<br /> <br /> To fix this, let&amp;#39;s place resource initialization above the registration<br /> of a generic netlink family.<br /> <br /> Found by InfoTeCS on behalf of Linux Verification Center<br /> (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: drop secpath at the same time as we currently drop dst<br /> <br /> Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while<br /> running tests that boil down to:<br /> - create a pair of netns<br /> - run a basic TCP test over ipcomp6<br /> - delete the pair of netns<br /> <br /> The xfrm_state found on spi_byaddr was not deleted at the time we<br /> delete the netns, because we still have a reference on it. This<br /> lingering reference comes from a secpath (which holds a ref on the<br /> xfrm_state), which is still attached to an skb. This skb is not<br /> leaked, it ends up on sk_receive_queue and then gets defer-free&amp;#39;d by<br /> skb_attempt_defer_free.<br /> <br /> The problem happens when we defer freeing an skb (push it on one CPU&amp;#39;s<br /> defer_list), and don&amp;#39;t flush that list before the netns is deleted. In<br /> that case, we still have a reference on the xfrm_state that we don&amp;#39;t<br /> expect at this point.<br /> <br /> We already drop the skb&amp;#39;s dst in the TCP receive path when it&amp;#39;s no<br /> longer needed, so let&amp;#39;s also drop the secpath. At this point,<br /> tcp_filter has already called into the LSM hooks that may require the<br /> secpath, so it should not be needed anymore. However, in some of those<br /> places, the MPTCP extension has just been attached to the skb, so we<br /> cannot simply drop all extensions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl().<br /> <br /> Brad Spengler reported the list_del() corruption splat in<br /> gtp_net_exit_batch_rtnl(). [0]<br /> <br /> Commit eb28fd76c0a0 ("gtp: Destroy device along with udp socket&amp;#39;s netns<br /> dismantle.") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl()<br /> to destroy devices in each netns as done in geneve and ip tunnels.<br /> <br /> However, this could trigger -&gt;dellink() twice for the same device during<br /> -&gt;exit_batch_rtnl().<br /> <br /> Say we have two netns A &amp; B and gtp device B that resides in netns B but<br /> whose UDP socket is in netns A.<br /> <br /> 1. cleanup_net() processes netns A and then B.<br /> <br /> 2. gtp_net_exit_batch_rtnl() finds the device B while iterating<br /> netns A&amp;#39;s gn-&gt;gtp_dev_list and calls -&gt;dellink().<br /> <br /> [ device B is not yet unlinked from netns B<br /> as unregister_netdevice_many() has not been called. ]<br /> <br /> 3. gtp_net_exit_batch_rtnl() finds the device B while iterating<br /> netns B&amp;#39;s for_each_netdev() and calls -&gt;dellink().<br /> <br /> gtp_dellink() cleans up the device&amp;#39;s hash table, unlinks the dev from<br /> gn-&gt;gtp_dev_list, and calls unregister_netdevice_queue().<br /> <br /> Basically, calling gtp_dellink() multiple times is fine unless<br /> CONFIG_DEBUG_LIST is enabled.<br /> <br /> Let&amp;#39;s remove for_each_netdev() in gtp_net_exit_batch_rtnl() and<br /> delegate the destruction to default_device_exit_batch() as done<br /> in bareudp.<br /> <br /> [0]:<br /> list_del corruption, ffff8880aaa62c00-&gt;next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04)<br /> kernel BUG at lib/list_debug.c:58!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1<br /> Tainted: [T]=RANDSTRUCT<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58<br /> Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60<br /> RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283<br /> RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054<br /> RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000<br /> RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32<br /> R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4<br /> R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08<br /> RBX: kasan shadow of 0x0<br /> RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554<br /> RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58<br /> RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71<br /> RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]<br /> RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ]<br /> R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ]<br /> R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ]<br /> R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object]<br /> FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0<br /> Stack:<br /> 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00<br /> ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005<br /> 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d<br /> Call Trace:<br /> <br /> [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28<br /> [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28<br /> [] list_del include/linux/list.h:262 [inl<br /> ---truncated---

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.