Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: imx8ulp: correct the flexspi compatible string<br /> <br /> The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has<br /> 32 LUTs, so correct the compatible string here, otherwise will<br /> meet below error:<br /> <br /> [ 1.119072] ------------[ cut here ]------------<br /> [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64<br /> [ 1.133239] Modules linked in:<br /> [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69<br /> [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT)<br /> [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64<br /> [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64<br /> [ 1.168060] sp : ffff80008002b2a0<br /> [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000<br /> [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0<br /> [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff<br /> [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002<br /> [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00<br /> [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80<br /> [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001<br /> [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6<br /> [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92<br /> [ 1.246267] Call trace:<br /> [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64<br /> [ 1.253031] spi_mem_exec_op+0x3a0/0x430<br /> [ 1.257139] spi_nor_read_id+0x80/0xcc<br /> [ 1.261065] spi_nor_scan+0x1ec/0xf10<br /> [ 1.264901] spi_nor_probe+0x108/0x2fc<br /> [ 1.268828] spi_mem_probe+0x6c/0xbc<br /> [ 1.272574] spi_probe+0x84/0xe4<br /> [ 1.275958] really_probe+0xbc/0x29c<br /> [ 1.279713] __driver_probe_device+0x78/0x12c<br /> [ 1.284277] driver_probe_device+0xd8/0x15c<br /> [ 1.288660] __device_attach_driver+0xb8/0x134<br /> [ 1.293316] bus_for_each_drv+0x88/0xe8<br /> [ 1.297337] __device_attach+0xa0/0x190<br /> [ 1.301353] device_initial_probe+0x14/0x20<br /> [ 1.305734] bus_probe_device+0xac/0xb0<br /> [ 1.309752] device_add+0x5d0/0x790<br /> [ 1.313408] __spi_add_device+0x134/0x204<br /> [ 1.317606] of_register_spi_device+0x3b4/0x590<br /> [ 1.322348] spi_register_controller+0x47c/0x754<br /> [ 1.327181] devm_spi_register_controller+0x4c/0xa4<br /> [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0<br /> [ 1.336307] platform_probe+0x68/0xc4<br /> [ 1.340145] really_probe+0xbc/0x29c<br /> [ 1.343893] __driver_probe_device+0x78/0x12c<br /> [ 1.348457] driver_probe_device+0xd8/0x15c<br /> [ 1.352838] __driver_attach+0x90/0x19c<br /> [ 1.356857] bus_for_each_dev+0x7c/0xdc<br /> [ 1.360877] driver_attach+0x24/0x30<br /> [ 1.364624] bus_add_driver+0xe4/0x208<br /> [ 1.368552] driver_register+0x5c/0x124<br /> [ 1.372573] __platform_driver_register+0x28/0x34<br /> [ 1.377497] nxp_fspi_driver_init+0x1c/0x28<br /> [ 1.381888] do_one_initcall+0x80/0x1c8<br /> [ 1.385908] kernel_init_freeable+0x1c4/0x28c<br /> [ 1.390472] kernel_init+0x20/0x1d8<br /> [ 1.394138] ret_from_fork+0x10/0x20<br /> [ 1.397885] ---[ end trace 0000000000000000 ]---<br /> [ 1.407908] ------------[ cut here ]------------

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()<br /> <br /> There are code paths from which the function is called without holding<br /> the RCU read lock, resulting in a suspicious RCU usage warning [1].<br /> <br /> Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire<br /> the RCU read lock before calling<br /> l3mdev_master_upper_ifindex_by_index_rcu().<br /> <br /> [1]<br /> WARNING: suspicious RCU usage<br /> 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted<br /> -----------------------------<br /> net/core/dev.c:876 RCU-list traversed in non-reader section!!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by ip/361:<br /> #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60<br /> <br /> stack backtrace:<br /> CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141<br /> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xba/0x110<br /> lockdep_rcu_suspicious.cold+0x4f/0xd6<br /> dev_get_by_index_rcu+0x1d3/0x210<br /> l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0<br /> ip_tunnel_bind_dev+0x72f/0xa00<br /> ip_tunnel_newlink+0x368/0x7a0<br /> ipgre_newlink+0x14c/0x170<br /> __rtnl_newlink+0x1173/0x19c0<br /> rtnl_newlink+0x6c/0xa0<br /> rtnetlink_rcv_msg+0x3cc/0xf60<br /> netlink_rcv_skb+0x171/0x450<br /> netlink_unicast+0x539/0x7f0<br /> netlink_sendmsg+0x8c1/0xd80<br /> ____sys_sendmsg+0x8f9/0xc20<br /> ___sys_sendmsg+0x197/0x1e0<br /> __sys_sendmsg+0x122/0x1f0<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp i2c: handle NULL header address<br /> <br /> daddr can be NULL if there is no neighbour table entry present,<br /> in that case the tx packet should be dropped.<br /> <br /> saddr will usually be set by MCTP core, but check for NULL in case a<br /> packet is transmitted by a different protocol.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> resource,kexec: walk_system_ram_res_rev must retain resource flags<br /> <br /> walk_system_ram_res_rev() erroneously discards resource flags when passing<br /> the information to the callback.<br /> <br /> This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have<br /> these resources selected during kexec to store kexec buffers if that<br /> memory happens to be at placed above normal system ram.<br /> <br /> This leads to undefined behavior after reboot. If the kexec buffer is<br /> never touched, nothing happens. If the kexec buffer is touched, it could<br /> lead to a crash (like below) or undefined behavior.<br /> <br /> Tested on a system with CXL memory expanders with driver managed memory,<br /> TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk&amp;#39;s showed the flags<br /> were being discarded and as a result the check for<br /> IORESOURCE_SYSRAM_DRIVER_MANAGED passes.<br /> <br /> find_next_iomem_res: name(System RAM (kmem))<br /> start(10000000000)<br /> end(1034fffffff)<br /> flags(83000200)<br /> <br /> locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0)<br /> <br /> [.] BUG: unable to handle page fault for address: ffff89834ffff000<br /> [.] #PF: supervisor read access in kernel mode<br /> [.] #PF: error_code(0x0000) - not-present page<br /> [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0<br /> [.] Oops: 0000 [#1] SMP<br /> [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0<br /> [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286<br /> [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000<br /> [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018<br /> [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900<br /> [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000<br /> [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000<br /> [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000<br /> [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [.] ata5: SATA link down (SStatus 0 SControl 300)<br /> [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0<br /> [.] PKRU: 55555554<br /> [.] Call Trace:<br /> [.] <br /> [.] ? __die+0x78/0xc0<br /> [.] ? page_fault_oops+0x2a8/0x3a0<br /> [.] ? exc_page_fault+0x84/0x130<br /> [.] ? asm_exc_page_fault+0x22/0x30<br /> [.] ? ima_restore_measurement_list+0x95/0x4b0<br /> [.] ? template_desc_init_fields+0x317/0x410<br /> [.] ? crypto_alloc_tfm_node+0x9c/0xc0<br /> [.] ? init_ima_lsm+0x30/0x30<br /> [.] ima_load_kexec_buffer+0x72/0xa0<br /> [.] ima_init+0x44/0xa0<br /> [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0<br /> [.] ? init_ima_lsm+0x30/0x30<br /> [.] do_one_initcall+0xad/0x200<br /> [.] ? idr_alloc_cyclic+0xaa/0x110<br /> [.] ? new_slab+0x12c/0x420<br /> [.] ? new_slab+0x12c/0x420<br /> [.] ? number+0x12a/0x430<br /> [.] ? sysvec_apic_timer_interrupt+0xa/0x80<br /> [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> [.] ? parse_args+0xd4/0x380<br /> [.] ? parse_args+0x14b/0x380<br /> [.] kernel_init_freeable+0x1c1/0x2b0<br /> [.] ? rest_init+0xb0/0xb0<br /> [.] kernel_init+0x16/0x1a0<br /> [.] ret_from_fork+0x2f/0x40<br /> [.] ? rest_init+0xb0/0xb0<br /> [.] ret_from_fork_asm+0x11/0x20<br /> [.]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()<br /> <br /> The per-netns IP tunnel hash table is protected by the RTNL mutex and<br /> ip_tunnel_find() is only called from the control path where the mutex is<br /> taken.<br /> <br /> Add a lockdep expression to hlist_for_each_entry_rcu() in<br /> ip_tunnel_find() in order to validate that the mutex is held and to<br /> silence the suspicious RCU usage warning [1].<br /> <br /> [1]<br /> WARNING: suspicious RCU usage<br /> 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted<br /> -----------------------------<br /> net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by ip/362:<br /> #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60<br /> <br /> stack backtrace:<br /> CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139<br /> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xba/0x110<br /> lockdep_rcu_suspicious.cold+0x4f/0xd6<br /> ip_tunnel_find+0x435/0x4d0<br /> ip_tunnel_newlink+0x517/0x7a0<br /> ipgre_newlink+0x14c/0x170<br /> __rtnl_newlink+0x1173/0x19c0<br /> rtnl_newlink+0x6c/0xa0<br /> rtnetlink_rcv_msg+0x3cc/0xf60<br /> netlink_rcv_skb+0x171/0x450<br /> netlink_unicast+0x539/0x7f0<br /> netlink_sendmsg+0x8c1/0xd80<br /> ____sys_sendmsg+0x8f9/0xc20<br /> ___sys_sendmsg+0x197/0x1e0<br /> __sys_sendmsg+0x122/0x1f0<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

A vulnerability was found in Weaver E-cology allows attackers use race conditions to bypass security mechanisms to upload malicious files and control server privileges

An issue in Weaver E-cology v. attackers construct special requests to insert remote malicious code and to trigger malicious code execution, and control server privileges

Weaver Ecology v9.* was discovered to contain a SQL injection vulnerability via the component /mobilemode/Action.jsp?invoker=com.weaver.formmodel.mobile.mec.servlet.MECAction&amp;action=getFieldTriggerValue&amp;searchField=*&amp;fromTable=HrmResourceManager&amp;whereClause=1%3d1&amp;triggerCondition=1&amp;expression=%3d&amp;fieldValue=1.

Qualys discovered that needrestart, before version 3.8, allows local attackers to execute arbitrary code as root by tricking needrestart into running the Python interpreter with an attacker-controlled PYTHONPATH environment variable.

Qualys discovered that needrestart, before version 3.8, allows local attackers to execute arbitrary code as root by winning a race condition and tricking needrestart into running their own, fake Python interpreter (instead of the system&amp;#39;s real Python interpreter). The initial security fix (6ce6136) introduced a regression which was subsequently resolved (42af5d3).

Qualys discovered that needrestart, before version 3.8, allows local attackers to execute arbitrary code as root by tricking needrestart into running the Ruby interpreter with an attacker-controlled RUBYLIB environment variable.

The Versa Director uses PostgreSQL (Postgres) to store operational and configuration data. It is also needed for High Availability function of the Versa Director. The default configuration has a common password across all instances of Versa Director. By default, Versa Director configures Postgres to listen on all network interfaces. This combination allows an unauthenticated attacker to access and administer the database or read local filesystem contents to escalate privileges on the system. <br /> <br /> Exploitation Status:<br /> Versa Networks is not aware of this exploitation in any production systems. A proof of concept exists in the lab environment.<br /> <br /> Workarounds or Mitigation:<br /> Starting with the latest 22.1.4 version of Versa Director, the software will automatically restrict access to the Postgres and HA ports to only the local and peer Versa Directors. For older releases, Versa recommends performing manual hardening of HA ports. Please refer to the following link for the steps https://docs.versa-networks.com/Solutions/System_Hardening/Perform_Manual_Hardening_for_Versa_Director#Secure_HA_Ports <br /> <br /> This vulnerability is not exploitable on Versa Directors if published Firewall guidelines are implemented. We have validated that no Versa-hosted head ends have been affected by this vulnerability. All Versa-hosted head ends are patched and hardened. <br /> <br /> Please contact Versa Technical Support or Versa account team for any further assistance.<br /> <br /> Software Download Links:<br /> 22.1.4: https://support.versa-networks.com/support/solutions/articles/23000026708-release-22-1-4