Vulnerabilities

Vulnerability in the Oracle iStore product of Oracle E-Business Suite (component: Shopping Cart). Supported versions that are affected are 12.1.1, 12.1.2, 12.1.3, 12.2.3, 12.2.4, 12.2.5, 12.2.6, 12.2.7 and 12.2.8. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle iStore. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle iStore, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle iStore accessible data as well as unauthorized update, insert or delete access to some of Oracle iStore accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).

A SQL injection in the Amazon Redshift Python Connector v2.1.4 allows a user to gain escalated privileges via the get_schemas, get_tables, or get_columns Metadata APIs. Users are recommended to upgrade to the driver version 2.1.5 or revert to driver version 2.1.3.

A SQL injection in the Amazon Redshift ODBC Driver v2.1.5.0 (Windows or Linux) allows a user to gain escalated privileges via the SQLTables or SQLColumns Metadata APIs. Users are recommended to upgrade to the driver version 2.1.6.0 or revert to driver version 2.1.4.0.

A SQL injection in the Amazon Redshift JDBC Driver in v2.1.0.31 allows a user to gain escalated privileges via the getSchemas, getTables, or getColumns Metadata APIs. Users should upgrade to the driver version 2.1.0.32 or revert to driver version 2.1.0.30.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu<br /> <br /> KCSAN reports a data race when access the krcp-&gt;monitor_work.timer.expires<br /> variable in the schedule_delayed_monitor_work() function:<br /> <br /> <br /> BUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu<br /> <br /> read to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1:<br /> schedule_delayed_monitor_work kernel/rcu/tree.c:3520 [inline]<br /> kvfree_call_rcu+0x3b8/0x510 kernel/rcu/tree.c:3839<br /> trie_update_elem+0x47c/0x620 kernel/bpf/lpm_trie.c:441<br /> bpf_map_update_value+0x324/0x350 kernel/bpf/syscall.c:203<br /> generic_map_update_batch+0x401/0x520 kernel/bpf/syscall.c:1849<br /> bpf_map_do_batch+0x28c/0x3f0 kernel/bpf/syscall.c:5143<br /> __sys_bpf+0x2e5/0x7a0<br /> __do_sys_bpf kernel/bpf/syscall.c:5741 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5739 [inline]<br /> __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5739<br /> x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> write to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0:<br /> __mod_timer+0x578/0x7f0 kernel/time/timer.c:1173<br /> add_timer_global+0x51/0x70 kernel/time/timer.c:1330<br /> __queue_delayed_work+0x127/0x1a0 kernel/workqueue.c:2523<br /> queue_delayed_work_on+0xdf/0x190 kernel/workqueue.c:2552<br /> queue_delayed_work include/linux/workqueue.h:677 [inline]<br /> schedule_delayed_monitor_work kernel/rcu/tree.c:3525 [inline]<br /> kfree_rcu_monitor+0x5e8/0x660 kernel/rcu/tree.c:3643<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3310<br /> worker_thread+0x51d/0x6f0 kernel/workqueue.c:3391<br /> kthread+0x1d1/0x210 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: events_unbound kfree_rcu_monitor<br /> <br /> <br /> kfree_rcu_monitor() rearms the work if a "krcp" has to be still<br /> offloaded and this is done without holding krcp-&gt;lock, whereas<br /> the kvfree_call_rcu() holds it.<br /> <br /> Fix it by acquiring the "krcp-&gt;lock" for kfree_rcu_monitor() so<br /> both functions do not race anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat/qat_4xxx - fix off by one in uof_get_name()<br /> <br /> The fw_objs[] array has "num_objs" elements so the &gt; needs to be &gt;= to<br /> prevent an out of bounds read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat/qat_420xx - fix off by one in uof_get_name()<br /> <br /> This is called from uof_get_name_420xx() where "num_objs" is the<br /> ARRAY_SIZE() of fw_objs[]. The &gt; needs to be &gt;= to prevent an out of<br /> bounds access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()<br /> <br /> This loop is supposed to break if the frequency returned from<br /> clk_round_rate() is the same as on the previous iteration. However,<br /> that check doesn&amp;#39;t make sense on the first iteration through the loop.<br /> It leads to reading before the start of these-&gt;clk_perf_tbl[] array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/bluefield: Fix potential integer overflow<br /> <br /> The 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idx<br /> left-shifted 16 bits and OR-ed with DIMM index. With mem_ctrl_idx defined as<br /> 32-bits wide the left-shift operation truncates the upper 16 bits of<br /> information during the calculation of the SMC argument.<br /> <br /> The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent any<br /> potential integer overflow, i.e. loss of data from upper 16 bits.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: glink: fix off-by-one in connector_status<br /> <br /> UCSI connector&amp;#39;s indices start from 1 up to 3, PMIC_GLINK_MAX_PORTS.<br /> Correct the condition in the pmic_glink_ucsi_connector_status()<br /> callback, fixing Type-C orientation reporting for the third USB-C<br /> connector.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()<br /> <br /> Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF<br /> deinit notify function pci_epc_deinit_notify() are called during the<br /> execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted<br /> PERST#. But quickly after this step, refclk will also be disabled by the<br /> host.<br /> <br /> All of the tegra194 endpoint SoCs supported as of now depend on the refclk<br /> from the host for keeping the controller operational. Due to this<br /> limitation, any access to the hardware registers in the absence of refclk<br /> will result in a whole endpoint crash. Unfortunately, most of the<br /> controller cleanups require accessing the hardware registers (like eDMA<br /> cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup<br /> functions can cause the crash in the endpoint SoC once host asserts PERST#.<br /> <br /> One way to address this issue is by generating the refclk in the endpoint<br /> itself and not depending on the host. But that is not always possible as<br /> some of the endpoint designs do require the endpoint to consume refclk from<br /> the host.<br /> <br /> Thus, fix this crash by moving the controller cleanups to the start of<br /> the pex_ep_event_pex_rst_deassert() function. This function is called<br /> whenever the host has deasserted PERST# and it is guaranteed that the<br /> refclk would be active at this point. So at the start of this function<br /> (after enabling resources) the controller cleanup can be performed. Once<br /> finished, rest of the code execution for PERST# deassert can continue as<br /> usual.