Name |
Description |
CVE-2024-53123 |
In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 <f7> 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7feb5d857559 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.
|
CVE-2024-49330 |
Unrestricted Upload of File with Dangerous Type vulnerability in brx8r Nice Backgrounds allows Upload a Web Shell to a Web Server.This issue affects Nice Backgrounds: from n/a through 1.0.
|
CVE-2024-46837 |
In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Restrict high priorities on group_create We were allowing any users to create a high priority group without any permission checks. As a result, this was allowing possible denial of service. We now only allow the DRM master or users with the CAP_SYS_NICE capability to set higher priorities than PANTHOR_GROUP_PRIORITY_MEDIUM. As the sole user of that uAPI lives in Mesa and hardcode a value of MEDIUM [1], this should be safe to do. Additionally, as those checks are performed at the ioctl level, panthor_group_create now only check for priority level validity. [1]https://gitlab.freedesktop.org/mesa/mesa/-/blob/f390835074bdf162a63deb0311d1a6de527f9f89/src/gallium/drivers/panfrost/pan_csf.c#L1038
|
CVE-2024-44973 |
In the Linux kernel, the following vulnerability has been resolved: mm, slub: do not call do_slab_free for kfence object In 782f8906f805 the freeing of kfence objects was moved from deep inside do_slab_free to the wrapper functions outside. This is a nice change, but unfortunately it missed one spot in __kmem_cache_free_bulk. This results in a crash like this: BUG skbuff_head_cache (Tainted: G S B E ): Padding overwritten. 0xffff88907fea0f00-0xffff88907fea0fff @offset=3840 slab_err (mm/slub.c:1129) free_to_partial_list (mm/slub.c:? mm/slub.c:4036) slab_pad_check (mm/slub.c:864 mm/slub.c:1290) check_slab (mm/slub.c:?) free_to_partial_list (mm/slub.c:3171 mm/slub.c:4036) kmem_cache_alloc_bulk (mm/slub.c:? mm/slub.c:4495 mm/slub.c:4586 mm/slub.c:4635) napi_build_skb (net/core/skbuff.c:348 net/core/skbuff.c:527 net/core/skbuff.c:549) All the other callers to do_slab_free appear to be ok. Add a kfence_free check in __kmem_cache_free_bulk to avoid the crash.
|
CVE-2024-36904 |
In the Linux kernel, the following vulnerability has been resolved: tcp: Use refcount_inc_not_zero() in tcp_twsk_unique(). Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis. Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock. Thus, there is a small race window where other threads could try to reuse the port during connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt. If that happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else. To avoid the use-after-free, we need to use refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false. [0]: refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? report_bug+0x171/0x1a0 ? refcount_warn_saturate+0xe5/0x110 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110 tcp_twsk_unique+0x186/0x190 __inet_check_established+0x176/0x2d0 __inet_hash_connect+0x74/0x7d0 ? __pfx___inet_check_established+0x10/0x10 tcp_v4_connect+0x278/0x530 __inet_stream_connect+0x10f/0x3d0 inet_stream_connect+0x3a/0x60 __sys_connect+0xa8/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0x83/0x170 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK>
|
CVE-2024-35917 |
In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Fix bpf_plt pointer arithmetic Kui-Feng Lee reported a crash on s390x triggered by the dummy_st_ops/dummy_init_ptr_arg test [1]: [<0000000000000002>] 0x2 [<00000000009d5cde>] bpf_struct_ops_test_run+0x156/0x250 [<000000000033145a>] __sys_bpf+0xa1a/0xd00 [<00000000003319dc>] __s390x_sys_bpf+0x44/0x50 [<0000000000c4382c>] __do_syscall+0x244/0x300 [<0000000000c59a40>] system_call+0x70/0x98 This is caused by GCC moving memcpy() after assignments in bpf_jit_plt(), resulting in NULL pointers being written instead of the return and the target addresses. Looking at the GCC internals, the reordering is allowed because the alias analysis thinks that the memcpy() destination and the assignments' left-hand-sides are based on different objects: new_plt and bpf_plt_ret/bpf_plt_target respectively, and therefore they cannot alias. This is in turn due to a violation of the C standard: When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object ... From the C's perspective, bpf_plt_ret and bpf_plt are distinct objects and cannot be subtracted. In the practical terms, doing so confuses the GCC's alias analysis. The code was written this way in order to let the C side know a few offsets defined in the assembly. While nice, this is by no means necessary. Fix the noncompliance by hardcoding these offsets. [1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/
|
CVE-2024-26992 |
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/pmu: Disable support for adaptive PEBS Drop support for virtualizing adaptive PEBS, as KVM's implementation is architecturally broken without an obvious/easy path forward, and because exposing adaptive PEBS can leak host LBRs to the guest, i.e. can leak host kernel addresses to the guest. Bug #1 is that KVM doesn't account for the upper 32 bits of IA32_FIXED_CTR_CTRL when (re)programming fixed counters, e.g fixed_ctrl_field() drops the upper bits, reprogram_fixed_counters() stores local variables as u8s and truncates the upper bits too, etc. Bug #2 is that, because KVM _always_ sets precise_ip to a non-zero value for PEBS events, perf will _always_ generate an adaptive record, even if the guest requested a basic record. Note, KVM will also enable adaptive PEBS in individual *counter*, even if adaptive PEBS isn't exposed to the guest, but this is benign as MSR_PEBS_DATA_CFG is guaranteed to be zero, i.e. the guest will only ever see Basic records. Bug #3 is in perf. intel_pmu_disable_fixed() doesn't clear the upper bits either, i.e. leaves ICL_FIXED_0_ADAPTIVE set, and intel_pmu_enable_fixed() effectively doesn't clear ICL_FIXED_0_ADAPTIVE either. I.e. perf _always_ enables ADAPTIVE counters, regardless of what KVM requests. Bug #4 is that adaptive PEBS *might* effectively bypass event filters set by the host, as "Updated Memory Access Info Group" records information that might be disallowed by userspace via KVM_SET_PMU_EVENT_FILTER. Bug #5 is that KVM doesn't ensure LBR MSRs hold guest values (or at least zeros) when entering a vCPU with adaptive PEBS, which allows the guest to read host LBRs, i.e. host RIPs/addresses, by enabling "LBR Entries" records. Disable adaptive PEBS support as an immediate fix due to the severity of the LBR leak in particular, and because fixing all of the bugs will be non-trivial, e.g. not suitable for backporting to stable kernels. Note! This will break live migration, but trying to make KVM play nice with live migration would be quite complicated, wouldn't be guaranteed to work (i.e. KVM might still kill/confuse the guest), and it's not clear that there are any publicly available VMMs that support adaptive PEBS, let alone live migrate VMs that support adaptive PEBS, e.g. QEMU doesn't support PEBS in any capacity.
|
CVE-2024-26885 |
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix DEVMAP_HASH overflow check on 32-bit arches The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end. Syzbot managed to turn this into a crash on arm32 by creating a DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation.
|
CVE-2024-21609 |
A Missing Release of Memory after Effective Lifetime vulnerability in the IKE daemon (iked) of Juniper Networks Junos OS on MX Series with SPC3, and SRX Series allows an administratively adjacent attacker which is able to successfully establish IPsec tunnels to cause a Denial of Service (DoS). If specific values for the IPsec parameters local-ip, remote-ip, remote ike-id, and traffic selectors are sent from the peer, a memory leak occurs during every IPsec SA rekey which is carried out with a specific message sequence. This will eventually result in an iked process crash and restart. The iked process memory consumption can be checked using the below command: user@host> show system processes extensive | grep iked PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 56903 root 31 0 4016M 2543M CPU0 0 2:10 10.50% iked This issue affects Juniper Networks Junos OS: * All versions earlier than 20.4R3-S9; * 21.2 versions earlier than 21.2R3-S7; * 21.3 versions earlier than 21.3R3-S5; * 21.4 versions earlier than 21.4R3-S4; * 22.1 versions earlier than 22.1R3-S3; * 22.2 versions earlier than 22.2R3-S2; * 22.3 versions earlier than 22.3R3; * 22.4 versions earlier than 22.4R3; * 23.2 versions earlier than 23.2R1-S2, 23.2R2.
|
CVE-2023-44184 |
An Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability in the management daemon (mgd) process of Juniper Networks Junos OS and Junos OS Evolved allows a network-based authenticated low-privileged attacker, by executing a specific command via NETCONF, to cause a CPU Denial of Service to the device's control plane. This issue affects: Juniper Networks Junos OS * All versions prior to 20.4R3-S7; * 21.2 versions prior to 21.2R3-S5; * 21.3 versions prior to 21.3R3-S5; * 21.4 versions prior to 21.4R3-S4; * 22.1 versions prior to 22.1R3-S2; * 22.2 versions prior to 22.2R3; * 22.3 versions prior to 22.3R2-S1, 22.3R3; * 22.4 versions prior to 22.4R1-S2, 22.4R2. Juniper Networks Junos OS Evolved * All versions prior to 21.4R3-S4-EVO; * 22.1 versions prior to 22.1R3-S2-EVO; * 22.2 versions prior to 22.2R3-EVO; * 22.3 versions prior to 22.3R3-EVO; * 22.4 versions prior to 22.4R2-EVO. An indicator of compromise can be seen by first determining if the NETCONF client is logged in and fails to log out after a reasonable period of time and secondly reviewing the WCPU percentage for the mgd process by running the following command: mgd process example: user@device-re#> show system processes extensive | match "mgd|PID" | except last PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 92476 root 100 0 500M 89024K CPU3 3 57.5H 89.60% mgd <<<<<<<<<<< review the high cpu percentage. Example to check for NETCONF activity: While there is no specific command that shows a specific session in use for NETCONF, you can review logs for UI_LOG_EVENT with "client-mode 'netconf'" For example: mgd[38121]: UI_LOGIN_EVENT: User 'root' login, class 'super-user' [38121], ssh-connection '10.1.1.1 201 55480 10.1.1.2 22', client-mode 'netconf'
|
CVE-2023-44061 |
File Upload vulnerability in Simple and Nice Shopping Cart Script v.1.0 allows a remote attacker to execute arbitrary code via the upload function in the edit profile component.
|
CVE-2023-22686 |
Cross-Site Request Forgery (CSRF) vulnerability in TriniTronic Nice PayPal Button Lite plugin <= 1.3.5 versions.
|
CVE-2023-1497 |
A vulnerability was found in SourceCodester Simple and Nice Shopping Cart Script 1.0. It has been rated as critical. This issue affects some unknown processing of the file uploaderm.php. The manipulation of the argument submit leads to unrestricted upload. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-223397 was assigned to this vulnerability.
|
CVE-2022-42710 |
Nice (formerly Nortek) Linear eMerge E3-Series 0.32-08f, 0.32-07p, 0.32-07e, 0.32-09c, 0.32-09b, 0.32-09a, and 0.32-08e devices are vulnerable to Stored Cross-Site Scripting (XSS).
|
CVE-2022-39900 |
Improper access control vulnerability in Nice Catch prior to SMR Dec-2022 Release 1 allows physical attackers to access contents of all toast generated in the application installed in Secure Folder through Nice Catch.
|
CVE-2022-38639 |
A cross-site scripting (XSS) vulnerability in Markdown-Nice v1.8.22 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Community Posting field.
|
CVE-2022-2957 |
A vulnerability classified as critical was found in SourceCodester Simple and Nice Shopping Cart Script. Affected by this vulnerability is an unknown functionality of the file /mkshop/Men/profile.php. The manipulation of the argument mem_id leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-207001 was assigned to this vulnerability.
|
CVE-2022-2909 |
A vulnerability was found in SourceCodester Simple and Nice Shopping Cart Script. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file /mkshop/Men/profile.php. The manipulation leads to unrestricted upload. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-206845 was assigned to this vulnerability.
|
CVE-2022-2814 |
A vulnerability has been found in SourceCodester Simple and Nice Shopping Cart Script and classified as problematic. Affected by this vulnerability is an unknown functionality of the file /mkshope/login.php. The manipulation of the argument msg leads to cross site scripting. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-206401 was assigned to this vulnerability.
|
CVE-2022-22161 |
An Uncontrolled Resource Consumption vulnerability in the kernel of Juniper Networks Junos OS allows an unauthenticated network based attacker to cause 100% CPU load and the device to become unresponsive by sending a flood of traffic to the out-of-band management ethernet port. Continued receipted of a flood will create a sustained Denial of Service (DoS) condition. Once the flood subsides the system will recover by itself. An indication that the system is affected by this issue would be that an irq handled by the fman process is shown to be using a high percentage of CPU cycles like in the following example output: user@host> show system processes extensive ... PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 31 root -84 -187 0K 16K WAIT 22.2H 56939.26% irq96: fman0 This issue affects Juniper Networks Junos OS: All versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S9; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S7, 19.3R3-S4; 19.4 versions prior to 19.4R2-S5, 19.4R3-S5; 20.1 versions prior to 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R2-S2, 20.4R3; 21.1 versions prior to 21.1R2; 21.2 versions prior to 21.2R1-S1, 21.2R2.
|
CVE-2021-47349 |
In the Linux kernel, the following vulnerability has been resolved: mwifiex: bring down link before deleting interface We can deadlock when rmmod'ing the driver or going through firmware reset, because the cfg80211_unregister_wdev() has to bring down the link for us, ... which then grab the same wiphy lock. nl80211_del_interface() already handles a very similar case, with a nice description: /* * We hold RTNL, so this is safe, without RTNL opencount cannot * reach 0, and thus the rdev cannot be deleted. * * We need to do it for the dev_close(), since that will call * the netdev notifiers, and we need to acquire the mutex there * but don't know if we get there from here or from some other * place (e.g. "ip link set ... down"). */ mutex_unlock(&rdev->wiphy.mtx); ... Do similarly for mwifiex teardown, by ensuring we bring the link down first. Sample deadlock trace: [ 247.103516] INFO: task rmmod:2119 blocked for more than 123 seconds. [ 247.110630] Not tainted 5.12.4 #5 [ 247.115796] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 247.124557] task:rmmod state:D stack: 0 pid: 2119 ppid: 2114 flags:0x00400208 [ 247.133905] Call trace: [ 247.136644] __switch_to+0x130/0x170 [ 247.140643] __schedule+0x714/0xa0c [ 247.144548] schedule_preempt_disabled+0x88/0xf4 [ 247.149714] __mutex_lock_common+0x43c/0x750 [ 247.154496] mutex_lock_nested+0x5c/0x68 [ 247.158884] cfg80211_netdev_notifier_call+0x280/0x4e0 [cfg80211] [ 247.165769] raw_notifier_call_chain+0x4c/0x78 [ 247.170742] call_netdevice_notifiers_info+0x68/0xa4 [ 247.176305] __dev_close_many+0x7c/0x138 [ 247.180693] dev_close_many+0x7c/0x10c [ 247.184893] unregister_netdevice_many+0xfc/0x654 [ 247.190158] unregister_netdevice_queue+0xb4/0xe0 [ 247.195424] _cfg80211_unregister_wdev+0xa4/0x204 [cfg80211] [ 247.201816] cfg80211_unregister_wdev+0x20/0x2c [cfg80211] [ 247.208016] mwifiex_del_virtual_intf+0xc8/0x188 [mwifiex] [ 247.214174] mwifiex_uninit_sw+0x158/0x1b0 [mwifiex] [ 247.219747] mwifiex_remove_card+0x38/0xa0 [mwifiex] [ 247.225316] mwifiex_pcie_remove+0xd0/0xe0 [mwifiex_pcie] [ 247.231451] pci_device_remove+0x50/0xe0 [ 247.235849] device_release_driver_internal+0x110/0x1b0 [ 247.241701] driver_detach+0x5c/0x9c [ 247.245704] bus_remove_driver+0x84/0xb8 [ 247.250095] driver_unregister+0x3c/0x60 [ 247.254486] pci_unregister_driver+0x2c/0x90 [ 247.259267] cleanup_module+0x18/0xcdc [mwifiex_pcie]
|
CVE-2021-47044 |
In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix shift-out-of-bounds in load_balance() Syzbot reported a handful of occurrences where an sd->nr_balance_failed can grow to much higher values than one would expect. A successful load_balance() resets it to 0; a failed one increments it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an active balance, which will either set it to sd->cache_nice_tries+1 or reset it to 0. However, in case the to-be-active-balanced task is not allowed to run on env->dst_cpu, then the increment is done without any further modification. This could then be repeated ad nauseam, and would explain the absurdly high values reported by syzbot (86, 149). VincentG noted there is value in letting sd->cache_nice_tries grow, so the shift itself should be fixed. That means preventing: """ If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. """ Thus we need to cap the shift exponent to BITS_PER_TYPE(typeof(lefthand)) - 1. I had a look around for other similar cases via coccinelle: @expr@ position pos; expression E1; expression E2; @@ ( E1 >> E2@pos | E1 >> E2@pos ) @cst depends on expr@ position pos; expression expr.E1; constant cst; @@ ( E1 >> cst@pos | E1 << cst@pos ) @script:python depends on !cst@ pos << expr.pos; exp << expr.E2; @@ # Dirty hack to ignore constexpr if exp.upper() != exp: coccilib.report.print_report(pos[0], "Possible UB shift here") The only other match in kernel/sched is rq_clock_thermal() which employs sched_thermal_decay_shift, and that exponent is already capped to 10, so that one is fine.
|
CVE-2021-46972 |
In the Linux kernel, the following vulnerability has been resolved: ovl: fix leaked dentry Since commit 6815f479ca90 ("ovl: use only uppermetacopy state in ovl_lookup()"), overlayfs doesn't put temporary dentry when there is a metacopy error, which leads to dentry leaks when shutting down the related superblock: overlayfs: refusing to follow metacopy origin for (/file0) ... BUG: Dentry (____ptrval____){i=3f33,n=file3} still in use (1) [unmount of overlay overlay] ... WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1 ... RIP: 0010:umount_check.cold+0x107/0x14d ... Call Trace: d_walk+0x28c/0x950 ? dentry_lru_isolate+0x2b0/0x2b0 ? __kasan_slab_free+0x12/0x20 do_one_tree+0x33/0x60 shrink_dcache_for_umount+0x78/0x1d0 generic_shutdown_super+0x70/0x440 kill_anon_super+0x3e/0x70 deactivate_locked_super+0xc4/0x160 deactivate_super+0xfa/0x140 cleanup_mnt+0x22e/0x370 __cleanup_mnt+0x1a/0x30 task_work_run+0x139/0x210 do_exit+0xb0c/0x2820 ? __kasan_check_read+0x1d/0x30 ? find_held_lock+0x35/0x160 ? lock_release+0x1b6/0x660 ? mm_update_next_owner+0xa20/0xa20 ? reacquire_held_locks+0x3f0/0x3f0 ? __sanitizer_cov_trace_const_cmp4+0x22/0x30 do_group_exit+0x135/0x380 __do_sys_exit_group.isra.0+0x20/0x20 __x64_sys_exit_group+0x3c/0x50 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xae ... VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds. Have a nice day... This fix has been tested with a syzkaller reproducer.
|
CVE-2021-3982 |
Linux distributions using CAP_SYS_NICE for gnome-shell may be exposed to a privilege escalation issue. An attacker, with low privilege permissions, may take advantage of the way CAP_SYS_NICE is currently implemented and eventually load code to increase its process scheduler priority leading to possible DoS of other services running in the same machine.
|
CVE-2021-31368 |
An Uncontrolled Resource Consumption vulnerability in the kernel of Juniper Networks JUNOS OS allows an unauthenticated network based attacker to cause 100% CPU load and the device to become unresponsive by sending a flood of traffic to the out-of-band management ethernet port. Continued receipted of a flood will create a sustained Denial of Service (DoS) condition. Once the flood subsides the system will recover by itself. An indication that the system is affected by this issue would be that kernel and netisr process are shown to be using a lot of CPU cycles like in the following example output: user@host> show system processes extensive ... PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 16 root -72 - 0K 304K WAIT 1 839:40 88.96% intr{swi1: netisr 0} 0 root 97 - 0K 160K RUN 1 732:43 87.99% kernel{bcm560xgmac0 que} This issue affects Juniper Networks JUNOS OS on EX2300 Series, EX3400 Series, and ACX710: All versions prior to 18.1R3-S13; 18.2 versions prior to 18.2R3-S8; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R2-S8, 18.4R3-S9; 19.1 versions prior to 19.1R3-S5; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S4, 19.4R3-S3; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R3; 20.3 versions prior to 20.3R2-S1, 20.3R3; 20.4 versions prior to 20.4R2.
|
CVE-2021-0293 |
A vulnerability in Juniper Networks Junos OS caused by Missing Release of Memory after Effective Lifetime leads to a memory leak each time the CLI command 'show system connections extensive' is executed. The amount of memory leaked on each execution depends on the number of TCP connections from and to the system. Repeated execution will cause more memory to leak and eventually daemons that need to allocate additionally memory and ultimately the kernel to crash, which will result in traffic loss. Continued execution of this command will cause a sustained Denial of Service (DoS) condition. An administrator can use the following CLI command to monitor for increase in memory consumption of the netstat process, if it exists: user@junos> show system processes extensive | match "username|netstat" PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 21181 root 100 0 5458M 4913M CPU3 2 0:59 97.27% netstat The following log message might be observed if this issue happens: kernel: %KERN-3: pid 21181 (netstat), uid 0, was killed: out of swap space This issue affects Juniper Networks Junos OS 18.2 versions prior to 18.2R2-S8, 18.2R3-S7. 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R1-S8, 18.4R2-S6, 18.4R3-S7; 19.1 versions prior to 19.1R1-S6, 19.1R2-S2, 19.1R3-S4; 19.2 versions prior to 19.2R1-S6, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S1; 19.4 versions prior to 19.4R1-S4, 19.4R2-S3, 19.4R3-S1; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R2-S1, 20.2R3; 20.3 versions prior to 20.3R1-S1, 20.3R2; This issue does not affect Juniper Networks Junos OS versions prior to 18.2R1.
|
CVE-2020-1668 |
On Juniper Networks EX2300 Series, receipt of a stream of specific multicast packets by the layer2 interface can cause high CPU load, which could lead to traffic interruption. This issue occurs when multicast packets are received by the layer 2 interface. To check if the device has high CPU load due to this issue, the administrator can issue the following command: user@host> show chassis routing-engine Routing Engine status: ... Idle 2 percent the "Idle" value shows as low (2 % in the example above), and also the following command: user@host> show system processes summary ... PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 11639 root 52 0 283M 11296K select 12:15 44.97% eventd 11803 root 81 0 719M 239M RUN 251:12 31.98% fxpc{fxpc} the eventd and the fxpc processes might use higher WCPU percentage (respectively 44.97% and 31.98% in the above example). This issue affects Juniper Networks Junos OS on EX2300 Series: 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S5; 18.3 versions prior to 18.3R2-S4, 18.3R3-S3; 18.4 versions prior to 18.4R2-S5, 18.4R3-S4; 19.1 versions prior to 19.1R3-S2; 19.2 versions prior to 19.2R1-S5, 19.2R3; 19.3 versions prior to 19.3R2-S4, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2-S1, 19.4R3; 20.1 versions prior to 20.1R1-S2, 20.1R2.
|
CVE-2019-7727 |
In NICE Engage through 6.5, the default configuration binds an unauthenticated JMX/RMI interface to all network interfaces, without restricting registration of MBeans, which allows remote attackers to execute arbitrary code via the RMI protocol by using the JMX connector. The observed affected TCP port is 6338 but, based on the product's configuration, a different one could be vulnerable.
|
CVE-2018-0321 |
A vulnerability in Cisco Prime Collaboration Provisioning (PCP) could allow an unauthenticated, remote attacker to access the Java Remote Method Invocation (RMI) system. The vulnerability is due to an open port in the Network Interface and Configuration Engine (NICE) service. An attacker could exploit this vulnerability by accessing the open RMI system on an affected PCP instance. An exploit could allow the attacker to perform malicious actions that affect PCP and the devices that are connected to it. This vulnerability affects Cisco Prime Collaboration Provisioning (PCP) Releases 11.6 and prior. Cisco Bug IDs: CSCvd61746.
|
CVE-2017-8184 |
MTK platform in Huawei smart phones with software of earlier than Nice-AL00C00B160 versions, earlier than Nice-AL10C00B140 versions has a any memory access vulnerability. An attacker tricks a user into installing a malicious application on the smart phone, and send given parameter to cause to any memory access vulnerabilities, leading to sensitive information leakage.
|
CVE-2017-8183 |
MTK platform in Huawei smart phones with software of earlier than Nice-AL00C00B160 versions, earlier than Nice-AL10C00B140 versions has a any memory access vulnerability. An attacker tricks a user into installing a malicious application on the smart phone, and send given parameter to cause to any memory access vulnerabilities, leading to sensitive information leakage.
|
CVE-2017-8182 |
MTK platform in Huawei smart phones with software of earlier than Nice-AL00C00B160 versions, earlier than Nice-AL10C00B140 versions has a out-of-bound read vulnerability. An attacker tricks a user into installing a malicious application on the smart phone, and send given parameter and cause to memory out-of-bound read.
|
CVE-2017-8181 |
The camera driver of MTK platform in Huawei smart phones with software of versions earlier than Nice-AL00C00B155 has a arbitrary memory write vulnerability.Due to the insufficient input verification, an attacker tricks a user into installing a malicious application which has special privilege and sends a specific parameter to the driver of the smart phone, causing privilege escalation.
|
CVE-2017-8180 |
The camera driver of MTK platform in Huawei smart phones with software of versions earlier than Nice-AL00C00B155 has a buffer overflow vulnerability.Due to the insufficient input verification, an attacker tricks a user into installing a malicious application which has special privilege and sends a specific parameter to the driver of the smart phone, causing privilege escalation.
|
CVE-2017-8179 |
The camera driver of MTK platform in Huawei smart phones with software of versions earlier than Nice-AL00C00B155 has a buffer overflow vulnerability.Due to the insufficient input verification, an attacker tricks a user into installing a malicious application which has special privilege and sends a specific parameter to the driver of the smart phone, causing privilege escalation.
|
CVE-2017-2708 |
The 'Find Phone' function in Nice smartphones with software versions earlier before Nice-AL00C00B0135 has an authentication bypass vulnerability. An unauthenticated attacker may wipe and factory reset the phone by special steps. Due to missing authentication of the 'Find Phone' function, an attacker may exploit the vulnerability to bypass the 'Find Phone' function in order to use the phone normally.
|
CVE-2017-15988 |
Nice PHP FAQ Script allows SQL Injection via the index.php nice_theme parameter, a different vulnerability than CVE-2008-6525.
|
CVE-2014-4308 |
Multiple cross-site scripting (XSS) vulnerabilities in NICE Recording eXpress (aka Cybertech eXpress) before 6.5.5 allow remote attackers to inject arbitrary web script or HTML via the (1) USRLNM parameter to myaccount/mysettings.edit.validate.asp or the frame parameter to (2) iframe.picker.statchannels.asp, (3) iframe.picker.channelgroups.asp, (4) iframe.picker.extensions.asp, (5) iframe.picker.licenseusergroups.asp, (6) iframe.picker.licenseusers.asp, (7) iframe.picker.lookup.asp, or (8) iframe.picker.marks.asp in _ifr/.
|
CVE-2014-4305 |
Multiple SQL injection vulnerabilities in NICE Recording eXpress (aka Cybertech eXpress) 6.5.7 and earlier allow remote attackers to execute arbitrary SQL commands via unspecified vectors.
|
CVE-2010-5031 |
Cross-site scripting (XSS) vulnerability in index.php in fileNice 1.1 allows remote attackers to inject arbitrary web script or HTML via the sstring parameter (aka the Search Box). NOTE: some of these details are obtained from third party information.
|
CVE-2009-4624 |
SQL injection vulnerability in download.php in Nicecoder iDesk allows remote attackers to execute arbitrary SQL commands via the cat_id parameter, a different vector than CVE-2005-3843.
|
CVE-2008-6525 |
SQL injection vulnerability in the Admin Panel in Nice PHP FAQ Script (Knowledge base Script) allows remote attackers to execute arbitrary SQL commands via the Password parameter (aka the pass field).
|
CVE-2007-4503 |
SQL injection vulnerability in index.php in the Nice Talk component (com_nicetalk) 0.9.3 and earlier for Joomla! allows remote attackers to execute arbitrary SQL commands via the tagid parameter.
|
CVE-2007-4264 |
Multiple cross-site scripting (XSS) vulnerabilities in index.php in Kai Blankenhorn Bitfolge simple and nice index file (aka snif) 1.5.2 and earlier allow remote attackers to inject arbitrary web script or HTML via the (1) path and (2) download parameters.
|
CVE-2006-6285 |
** DISPUTED **
PHP remote file inclusion vulnerability in index.php in Kai Blankenhorn Bitfolge simple and nice index file (aka snif) 1.5.2 and earlier allows remote attackers to execute arbitrary PHP code via a URL in the externalConfig parameter. NOTE: CVE and other third parties dispute this vulnerability because $externalConfig is defined before use.
|
CVE-2005-4560 |
The Windows Graphical Device Interface library (GDI32.DLL) in Microsoft Windows allows remote attackers to execute arbitrary code via a Windows Metafile (WMF) format image with a crafted SETABORTPROC GDI Escape function call, related to the Windows Picture and Fax Viewer (SHIMGVW.DLL), a different vulnerability than CVE-2005-2123 and CVE-2005-2124, and as originally discovered in the wild on unionseek.com.
|
CVE-2003-1335 |
Directory traversal vulnerability in Kai Blankenhorn Bitfolge simple and nice index file (aka snif) before 1.2.5 allows remote attackers to download files from locations above the snif directory.
|
CVE-2003-1334 |
Cross-site scripting (XSS) vulnerability in Kai Blankenhorn Bitfolge simple and nice index file (aka snif) before 1.2.7 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors.
|
CVE-2001-0920 |
Format string vulnerability in auto nice daemon (AND) 1.0.4 and earlier allows a local user to possibly execute arbitrary code via a process name containing a format string.
|
CVE-2001-0823 |
The pmpost program in Performance Co-Pilot (PCP) before 2.2.1-3 allows a local user to gain privileges via a symlink attack on the NOTICES file in the PCP log directory (PCP_LOG_DIR).
|