Vulnerabilities

kurwov is a fast, dependency-free library for creating Markov Chains. An unsafe sanitization of dataset contents on the `MarkovData#getNext` method used in `Markov#generate` and `Markov#choose` allows a maliciously crafted string on the dataset to throw and stop the function from running properly. If a string contains a forbidden substring (i.e. `__proto__`) followed by a space character, the code will access a special property in `MarkovData#finalData` by removing the last character of the string, bypassing the dataset sanitization (as it is supposed to be already sanitized before this function is called). Any dataset can be contaminated with the substring making it unable to properly generate anything in some cases. This issue has been addressed in version 3.2.5 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix DMA mappings leak<br /> <br /> Fix leak, when user changes ring parameters.<br /> During reallocation of RX buffers, new DMA mappings are created for<br /> those buffers. New buffers with different RX ring count should<br /> substitute older ones, but those buffers were freed in ice_vsi_cfg_rxq<br /> and reallocated again with ice_alloc_rx_buf. kfree on rx_buf caused<br /> leak of already mapped DMA.<br /> Reallocate ZC with xdp_buf struct, when BPF program loads. Reallocate<br /> back to rx_buf, when BPF program unloads.<br /> If BPF program is loaded/unloaded and XSK pools are created, reallocate<br /> RX queues accordingly in XDP_SETUP_XSK_POOL handler.<br /> <br /> Steps for reproduction:<br /> while :<br /> do<br /> for ((i=0; i

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Fix use-after-free warning<br /> <br /> Fix the following use-after-free warning which is observed during<br /> controller reset:<br /> <br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: add a force flush to delay work when radeon<br /> <br /> Although radeon card fence and wait for gpu to finish processing current batch rings,<br /> there is still a corner case that radeon lockup work queue may not be fully flushed,<br /> and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to<br /> put device in D3hot state.<br /> Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.<br /> &gt; Configuration and Message requests are the only TLPs accepted by a Function in<br /> &gt; the D3hot state. All other received Requests must be handled as Unsupported Requests,<br /> &gt; and all received Completions may optionally be handled as Unexpected Completions.<br /> This issue will happen in following logs:<br /> Unable to handle kernel paging request at virtual address 00008800e0008010<br /> CPU 0 kworker/0:3(131): Oops 0<br /> pc = [] ra = [] ps = 0000 Tainted: G W<br /> pc is at si_gpu_check_soft_reset+0x3c/0x240<br /> ra is at si_dma_is_lockup+0x34/0xd0<br /> v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000<br /> t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258<br /> t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000<br /> s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018<br /> s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000<br /> s6 = fff00007ef07bd98<br /> a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008<br /> a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338<br /> t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800<br /> t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000<br /> gp = ffffffff81d89690 sp = 00000000aa814126<br /> Disabling lock debugging due to kernel taint<br /> Trace:<br /> [] si_dma_is_lockup+0x34/0xd0<br /> [] radeon_fence_check_lockup+0xd0/0x290<br /> [] process_one_work+0x280/0x550<br /> [] worker_thread+0x70/0x7c0<br /> [] worker_thread+0x130/0x7c0<br /> [] kthread+0x200/0x210<br /> [] worker_thread+0x0/0x7c0<br /> [] kthread+0x14c/0x210<br /> [] ret_from_kernel_thread+0x18/0x20<br /> [] kthread+0x0/0x210<br /> Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101<br /> 4821ed21<br /> So force lockup work queue flush to fix this problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921e: fix crash in chip reset fail<br /> <br /> In case of drv own fail in reset, we may need to run mac_reset several<br /> times. The sequence would trigger system crash as the log below.<br /> <br /> Because we do not re-enable/schedule "tx_napi" before disable it again,<br /> the process would keep waiting for state change in napi_diable(). To<br /> avoid the problem and keep status synchronize for each run, goto final<br /> resource handling if drv own failed.<br /> <br /> [ 5857.353423] mt7921e 0000:3b:00.0: driver own failed<br /> [ 5858.433427] mt7921e 0000:3b:00.0: Timeout for driver own<br /> [ 5859.633430] mt7921e 0000:3b:00.0: driver own failed<br /> [ 5859.633444] ------------[ cut here ]------------<br /> [ 5859.633446] WARNING: CPU: 6 at kernel/kthread.c:659 kthread_park+0x11d<br /> [ 5859.633717] Workqueue: mt76 mt7921_mac_reset_work [mt7921_common]<br /> [ 5859.633728] RIP: 0010:kthread_park+0x11d/0x150<br /> [ 5859.633736] RSP: 0018:ffff8881b676fc68 EFLAGS: 00010202<br /> ......<br /> [ 5859.633766] Call Trace:<br /> [ 5859.633768] <br /> [ 5859.633771] mt7921e_mac_reset+0x176/0x6f0 [mt7921e]<br /> [ 5859.633778] mt7921_mac_reset_work+0x184/0x3a0 [mt7921_common]<br /> [ 5859.633785] ? mt7921_mac_set_timing+0x520/0x520 [mt7921_common]<br /> [ 5859.633794] ? __kasan_check_read+0x11/0x20<br /> [ 5859.633802] process_one_work+0x7ee/0x1320<br /> [ 5859.633810] worker_thread+0x53c/0x1240<br /> [ 5859.633818] kthread+0x2b8/0x370<br /> [ 5859.633824] ? process_one_work+0x1320/0x1320<br /> [ 5859.633828] ? kthread_complete_and_exit+0x30/0x30<br /> [ 5859.633834] ret_from_fork+0x1f/0x30<br /> [ 5859.633842]

IBM Cognos Controller 10.4.1, 10.4.2, and 11.0.0 could allow a remote attacker to obtain sensitive information when a stack trace is returned in the browser. IBM X-Force ID: 245403.

IBM Cognos Controller 10.4.1, 10.4.2, and 11.0.0 is vulnerable to injection attacks in application logging by not sanitizing user provided data. IBM X-Force ID: 251463.

IBM Cognos Controller 10.4.1, 10.4.2, and 11.0.0 is vulnerable to SQL injection. A remote attacker could send specially crafted SQL statements, which could allow the attacker to view, add, modify or delete information in the back-end database. IBM X-Force ID: 262183.

IBM Cognos Controller 10.4.1, 10.4.2, and 11.0.0 could allow a remote user to enumerate usernames due to differentiating error messages on existing usernames. IBM X-Force ID: 199181.

A cross-site scripting (XSS) vulnerability in netis-systems MEX605 v2.00.06 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the getTimeZone function.

netis-systems MEX605 v2.00.06 allows attackers to execute arbitrary OS commands via a crafted payload to the tracert page.

netis-systems MEX605 v2.00.06 allows attackers to execute arbitrary OS commands via a crafted payload to the ping test page.