Vulnerabilities

IBM OpenPages 9.0 is vulnerable to information disclosure of sensitive information due to a weaker than expected security for certain REST end points related to workflow feature of OpenPages. An authenticated user is able to obtain certain information about Workflow related configuration and internal state.

Insecure Permissions vulnerability in Tenda CP3 Pro Firmware V22.5.4.93 allows the telnet service (telnetd) by default at boot via the initialization script /etc/init.d/eth.sh. This allows remote attackers to connect to the device s shell over the network, potentially without authentication if default or weak credentials are present

Folo organizes feeds content into one timeline. Using pull_request_target on .github/workflows/auto-fix-lint-format-commit.yml can be exploited by attackers, since untrusted code can be executed having full access to secrets (from the base repo). By exploiting the vulnerability is possible to exfiltrate GITHUB_TOKEN which has high privileges. GITHUB_TOKEN can be used to completely overtake the repo since the token has content write privileges. This vulnerability is fixed in commit 585c6a591440cd39f92374230ac5d65d7dd23d6a.

IBM OpenPages with Watson 8.3 and 9.0 could allow an authenticated user to obtain sensitive information that should only be available to privileged users.

mcp-remote is exposed to OS command injection when connecting to untrusted MCP servers due to crafted input from the authorization_endpoint response URL

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs-schemes: free old damon_sysfs_scheme_filter-&gt;memcg_path on write<br /> <br /> memcg_path_store() assigns a newly allocated memory buffer to<br /> filter-&gt;memcg_path, without deallocating the previously allocated and<br /> assigned memory buffer. As a result, users can leak kernel memory by<br /> continuously writing a data to memcg_path DAMOS sysfs file. Fix the leak<br /> by deallocating the previously set memory buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: wcd9335: Fix missing free of regulator supplies<br /> <br /> Driver gets and enables all regulator supplies in probe path<br /> (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup<br /> in final error paths and in unbind (missing remove() callback). This<br /> leads to leaked memory and unbalanced regulator enable count during<br /> probe errors or unbind.<br /> <br /> Fix this by converting entire code into devm_regulator_bulk_get_enable()<br /> which also greatly simplifies the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: handle csum tree error with rescue=ibadroots correctly<br /> <br /> [BUG]<br /> There is syzbot based reproducer that can crash the kernel, with the<br /> following call trace: (With some debug output added)<br /> <br /> DEBUG: rescue=ibadroots parsed<br /> BTRFS: device fsid 14d642db-7b15-43e4-81e6-4b8fac6a25f8 devid 1 transid 8 /dev/loop0 (7:0) scanned by repro (1010)<br /> BTRFS info (device loop0): first mount of filesystem 14d642db-7b15-43e4-81e6-4b8fac6a25f8<br /> BTRFS info (device loop0): using blake2b (blake2b-256-generic) checksum algorithm<br /> BTRFS info (device loop0): using free-space-tree<br /> BTRFS warning (device loop0): checksum verify failed on logical 5312512 mirror 1 wanted 0xb043382657aede36608fd3386d6b001692ff406164733d94e2d9a180412c6003 found 0x810ceb2bacb7f0f9eb2bf3b2b15c02af867cb35ad450898169f3b1f0bd818651 level 0<br /> DEBUG: read tree root path failed for tree csum, ret=-5<br /> BTRFS warning (device loop0): checksum verify failed on logical 5328896 mirror 1 wanted 0x51be4e8b303da58e6340226815b70e3a93592dac3f30dd510c7517454de8567a found 0x51be4e8b303da58e634022a315b70e3a93592dac3f30dd510c7517454de8567a level 0<br /> BTRFS warning (device loop0): checksum verify failed on logical 5292032 mirror 1 wanted 0x1924ccd683be9efc2fa98582ef58760e3848e9043db8649ee382681e220cdee4 found 0x0cb6184f6e8799d9f8cb335dccd1d1832da1071d12290dab3b85b587ecacca6e level 0<br /> process &amp;#39;repro&amp;#39; launched &amp;#39;./file2&amp;#39; with NULL argv: empty string added<br /> DEBUG: no csum root, idatacsums=0 ibadroots=134217728<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]<br /> CPU: 5 UID: 0 PID: 1010 Comm: repro Tainted: G OE 6.15.0-custom+ #249 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022<br /> RIP: 0010:btrfs_lookup_csum+0x93/0x3d0 [btrfs]<br /> Call Trace:<br /> <br /> btrfs_lookup_bio_sums+0x47a/0xdf0 [btrfs]<br /> btrfs_submit_bbio+0x43e/0x1a80 [btrfs]<br /> submit_one_bio+0xde/0x160 [btrfs]<br /> btrfs_readahead+0x498/0x6a0 [btrfs]<br /> read_pages+0x1c3/0xb20<br /> page_cache_ra_order+0x4b5/0xc20<br /> filemap_get_pages+0x2d3/0x19e0<br /> filemap_read+0x314/0xde0<br /> __kernel_read+0x35b/0x900<br /> bprm_execve+0x62e/0x1140<br /> do_execveat_common.isra.0+0x3fc/0x520<br /> __x64_sys_execveat+0xdc/0x130<br /> do_syscall_64+0x54/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> [CAUSE]<br /> Firstly the fs has a corrupted csum tree root, thus to mount the fs we<br /> have to go "ro,rescue=ibadroots" mount option.<br /> <br /> Normally with that mount option, a bad csum tree root should set<br /> BTRFS_FS_STATE_NO_DATA_CSUMS flag, so that any future data read will<br /> ignore csum search.<br /> <br /> But in this particular case, we have the following call trace that<br /> caused NULL csum root, but not setting BTRFS_FS_STATE_NO_DATA_CSUMS:<br /> <br /> load_global_roots_objectid():<br /> <br /> ret = btrfs_search_slot();<br /> /* Succeeded */<br /> btrfs_item_key_to_cpu()<br /> found = true;<br /> /* We found the root item for csum tree. */<br /> root = read_tree_root_path();<br /> if (IS_ERR(root)) {<br /> if (!btrfs_test_opt(fs_info, IGNOREBADROOTS))<br /> /*<br /> * Since we have rescue=ibadroots mount option,<br /> * @ret is still 0.<br /> */<br /> break;<br /> if (!found || ret) {<br /> /* @found is true, @ret is 0, error handling for csum<br /> * tree is skipped.<br /> */<br /> }<br /> <br /> This means we completely skipped to set BTRFS_FS_STATE_NO_DATA_CSUMS if<br /> the csum tree is corrupted, which results unexpected later csum lookup.<br /> <br /> [FIX]<br /> If read_tree_root_path() failed, always populate @ret to the error<br /> number.<br /> <br /> As at the end of the function, we need @ret to determine if we need to<br /> do the extra error handling for csum tree.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: save the SR_SUM status over switches<br /> <br /> When threads/tasks are switched we need to ensure the old execution&amp;#39;s<br /> SR_SUM state is saved and the new thread has the old SR_SUM state<br /> restored.<br /> <br /> The issue was seen under heavy load especially with the syz-stress tool<br /> running, with crashes as follows in schedule_tail:<br /> <br /> Unable to handle kernel access to user memory without uaccess routines<br /> at virtual address 000000002749f0d0<br /> Oops [#1]<br /> Modules linked in:<br /> CPU: 1 PID: 4875 Comm: syz-executor.0 Not tainted<br /> 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0<br /> Hardware name: riscv-virtio,qemu (DT)<br /> epc : schedule_tail+0x72/0xb2 kernel/sched/core.c:4264<br /> ra : task_pid_vnr include/linux/sched.h:1421 [inline]<br /> ra : schedule_tail+0x70/0xb2 kernel/sched/core.c:4264<br /> epc : ffffffe00008c8b0 ra : ffffffe00008c8ae sp : ffffffe025d17ec0<br /> gp : ffffffe005d25378 tp : ffffffe00f0d0000 t0 : 0000000000000000<br /> t1 : 0000000000000001 t2 : 00000000000f4240 s0 : ffffffe025d17ee0<br /> s1 : 000000002749f0d0 a0 : 000000000000002a a1 : 0000000000000003<br /> a2 : 1ffffffc0cfac500 a3 : ffffffe0000c80cc a4 : 5ae9db91c19bbe00<br /> a5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba<br /> s2 : 0000000000040000 s3 : ffffffe00eef96c0 s4 : ffffffe022c77fe0<br /> s5 : 0000000000004000 s6 : ffffffe067d74e00 s7 : ffffffe067d74850<br /> s8 : ffffffe067d73e18 s9 : ffffffe067d74e00 s10: ffffffe00eef96e8<br /> s11: 000000ae6cdf8368 t3 : 5ae9db91c19bbe00 t4 : ffffffc4043cafb2<br /> t5 : ffffffc4043cafba t6 : 0000000000040000<br /> status: 0000000000000120 badaddr: 000000002749f0d0 cause:<br /> 000000000000000f<br /> Call Trace:<br /> [] schedule_tail+0x72/0xb2 kernel/sched/core.c:4264<br /> [] ret_from_exception+0x0/0x14<br /> Dumping ftrace buffer:<br /> (ftrace buffer empty)<br /> ---[ end trace b5f8f9231dc87dda ]---<br /> <br /> The issue comes from the put_user() in schedule_tail<br /> (kernel/sched/core.c) doing the following:<br /> <br /> asmlinkage __visible void schedule_tail(struct task_struct *prev)<br /> {<br /> ...<br /> if (current-&gt;set_child_tid)<br /> put_user(task_pid_vnr(current), current-&gt;set_child_tid);<br /> ...<br /> }<br /> <br /> the put_user() macro causes the code sequence to come out as follows:<br /> <br /> 1: __enable_user_access()<br /> 2: reg = task_pid_vnr(current);<br /> 3: *current-&gt;set_child_tid = reg;<br /> 4: __disable_user_access()<br /> <br /> The problem is that we may have a sleeping function as argument which<br /> could clear SR_SUM causing the panic above. This was fixed by<br /> evaluating the argument of the put_user() macro outside the user-enabled<br /> section in commit 285a76bb2cf5 ("riscv: evaluate put_user() arg before<br /> enabling user access")"<br /> <br /> In order for riscv to take advantage of unsafe_get/put_XXX() macros and<br /> to avoid the same issue we had with put_user() and sleeping functions we<br /> must ensure code flow can go through switch_to() from within a region of<br /> code with SR_SUM enabled and come back with SR_SUM still enabled. This<br /> patch addresses the problem allowing future work to enable full use of<br /> unsafe_get/put_XXX() macros without needing to take a CSR bit flip cost<br /> on every access. Make switch_to() save and restore SR_SUM.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: uartlite: register uart driver in init<br /> <br /> When two instances of uart devices are probing, a concurrency race can<br /> occur. If one thread calls uart_register_driver function, which first<br /> allocates and assigns memory to &amp;#39;uart_state&amp;#39; member of uart_driver<br /> structure, the other instance can bypass uart driver registration and<br /> call ulite_assign. This calls uart_add_one_port, which expects the uart<br /> driver to be fully initialized. This leads to a kernel panic due to a<br /> null pointer dereference:<br /> <br /> [ 8.143581] BUG: kernel NULL pointer dereference, address: 00000000000002b8<br /> [ 8.156982] #PF: supervisor write access in kernel mode<br /> [ 8.156984] #PF: error_code(0x0002) - not-present page<br /> [ 8.156986] PGD 0 P4D 0<br /> ...<br /> [ 8.180668] RIP: 0010:mutex_lock+0x19/0x30<br /> [ 8.188624] Call Trace:<br /> [ 8.188629] ? __die_body.cold+0x1a/0x1f<br /> [ 8.195260] ? page_fault_oops+0x15c/0x290<br /> [ 8.209183] ? __irq_resolve_mapping+0x47/0x80<br /> [ 8.209187] ? exc_page_fault+0x64/0x140<br /> [ 8.209190] ? asm_exc_page_fault+0x22/0x30<br /> [ 8.209196] ? mutex_lock+0x19/0x30<br /> [ 8.223116] uart_add_one_port+0x60/0x440<br /> [ 8.223122] ? proc_tty_register_driver+0x43/0x50<br /> [ 8.223126] ? tty_register_driver+0x1ca/0x1e0<br /> [ 8.246250] ulite_probe+0x357/0x4b0 [uartlite]<br /> <br /> To prevent it, move uart driver registration in to init function. This<br /> will ensure that uart_driver is always registered when probe function<br /> is called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: fix NULL pointer in cache_set_flush()<br /> <br /> 1. LINE#1794 - LINE#1887 is some codes about function of<br /> bch_cache_set_alloc().<br /> 2. LINE#2078 - LINE#2142 is some codes about function of<br /> register_cache_set().<br /> 3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098.<br /> <br /> 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)<br /> 1795 {<br /> ...<br /> 1860 if (!(c-&gt;devices = kcalloc(c-&gt;nr_uuids, sizeof(void *), GFP_KERNEL)) ||<br /> 1861 mempool_init_slab_pool(&amp;c-&gt;search, 32, bch_search_cache) ||<br /> 1862 mempool_init_kmalloc_pool(&amp;c-&gt;bio_meta, 2,<br /> 1863 sizeof(struct bbio) + sizeof(struct bio_vec) *<br /> 1864 bucket_pages(c)) ||<br /> 1865 mempool_init_kmalloc_pool(&amp;c-&gt;fill_iter, 1, iter_size) ||<br /> 1866 bioset_init(&amp;c-&gt;bio_split, 4, offsetof(struct bbio, bio),<br /> 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) ||<br /> 1868 !(c-&gt;uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||<br /> 1869 !(c-&gt;moving_gc_wq = alloc_workqueue("bcache_gc",<br /> 1870 WQ_MEM_RECLAIM, 0)) ||<br /> 1871 bch_journal_alloc(c) ||<br /> 1872 bch_btree_cache_alloc(c) ||<br /> 1873 bch_open_buckets_alloc(c) ||<br /> 1874 bch_bset_sort_state_init(&amp;c-&gt;sort, ilog2(c-&gt;btree_pages)))<br /> 1875 goto err;<br /> ^^^^^^^^<br /> 1876<br /> ...<br /> 1883 return c;<br /> 1884 err:<br /> 1885 bch_cache_set_unregister(c);<br /> ^^^^^^^^^^^^^^^^^^^^^^^^^^^<br /> 1886 return NULL;<br /> 1887 }<br /> ...<br /> 2078 static const char *register_cache_set(struct cache *ca)<br /> 2079 {<br /> ...<br /> 2098 c = bch_cache_set_alloc(&amp;ca-&gt;sb);<br /> 2099 if (!c)<br /> 2100 return err;<br /> ^^^^^^^^^^<br /> ...<br /> 2128 ca-&gt;set = c;<br /> 2129 ca-&gt;set-&gt;cache[ca-&gt;sb.nr_this_dev] = ca;<br /> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br /> ...<br /> 2138 return NULL;<br /> 2139 err:<br /> 2140 bch_cache_set_unregister(c);<br /> 2141 return err;<br /> 2142 }<br /> <br /> (1) If LINE#1860 - LINE#1874 is true, then do &amp;#39;goto err&amp;#39;(LINE#1875) and<br /> call bch_cache_set_unregister()(LINE#1885).<br /> (2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.<br /> (3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the<br /> value to c-&gt;cache[], it means that c-&gt;cache[] is NULL.<br /> <br /> LINE#1624 - LINE#1665 is some codes about function of cache_set_flush().<br /> As (1), in LINE#1885 call<br /> bch_cache_set_unregister()<br /> ---&gt; bch_cache_set_stop()<br /> ---&gt; closure_queue()<br /> -.-&gt; cache_set_flush() (as below LINE#1624)<br /> <br /> 1624 static void cache_set_flush(struct closure *cl)<br /> 1625 {<br /> ...<br /> 1654 for_each_cache(ca, c, i)<br /> 1655 if (ca-&gt;alloc_thread)<br /> ^^<br /> 1656 kthread_stop(ca-&gt;alloc_thread);<br /> ...<br /> 1665 }<br /> <br /> (4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the<br /> kernel crash occurred as below:<br /> [ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory<br /> [ 846.713242] bcache: register_bcache() error : failed to register device<br /> [ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered<br /> [ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8<br /> [ 846.714790] PGD 0 P4D 0<br /> [ 846.715129] Oops: 0000 [#1] SMP PTI<br /> [ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1<br /> [ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018<br /> [ 846.716451] Workqueue: events cache_set_flush [bcache]<br /> [ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache]<br /> [ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 8b b8 f8 09 00 0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: sanitize request list handling<br /> <br /> Validate the request in nvme_tcp_handle_r2t() to ensure it&amp;#39;s not part of<br /> any list, otherwise a malicious R2T PDU might inject a loop in request<br /> list processing.