Vulnerabilities

Deserialization of Untrusted Data vulnerability in reputeinfosystems ARPrice arprice allows Object Injection.This issue affects ARPrice: from n/a through

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in reputeinfosystems ARPrice arprice allows Reflected XSS.This issue affects ARPrice: from n/a through

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in NotFound Hero Mega Menu - Responsive WordPress Menu Plugin allows Reflected XSS. This issue affects Hero Mega Menu - Responsive WordPress Menu Plugin: from n/a through 1.16.5.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in NotFound Hero Mega Menu - Responsive WordPress Menu Plugin allows SQL Injection. This issue affects Hero Mega Menu - Responsive WordPress Menu Plugin: from n/a through 1.16.5.

Incorrect Privilege Assignment vulnerability in InspiryThemes Easy Real Estate easy-real-estate allows Privilege Escalation.This issue affects Easy Real Estate: from n/a through

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm thin: make get_first_thin use rcu-safe list first function<br /> <br /> The documentation in rculist.h explains the absence of list_empty_rcu()<br /> and cautions programmers against relying on a list_empty() -&gt;<br /> list_first() sequence in RCU safe code. This is because each of these<br /> functions performs its own READ_ONCE() of the list head. This can lead<br /> to a situation where the list_empty() sees a valid list entry, but the<br /> subsequent list_first() sees a different view of list head state after a<br /> modification.<br /> <br /> In the case of dm-thin, this author had a production box crash from a GP<br /> fault in the process_deferred_bios path. This function saw a valid list<br /> head in get_first_thin() but when it subsequently dereferenced that and<br /> turned it into a thin_c, it got the inside of the struct pool, since the<br /> list was now empty and referring to itself. The kernel on which this<br /> occurred printed both a warning about a refcount_t being saturated, and<br /> a UBSAN error for an out-of-bounds cpuid access in the queued spinlock,<br /> prior to the fault itself. When the resulting kdump was examined, it<br /> was possible to see another thread patiently waiting in thin_dtr&amp;#39;s<br /> synchronize_rcu.<br /> <br /> The thin_dtr call managed to pull the thin_c out of the active thins<br /> list (and have it be the last entry in the active_thins list) at just<br /> the wrong moment which lead to this crash.<br /> <br /> Fortunately, the fix here is straight forward. Switch get_first_thin()<br /> function to use list_first_or_null_rcu() which performs just a single<br /> READ_ONCE() and returns NULL if the list is already empty.<br /> <br /> This was run against the devicemapper test suite&amp;#39;s thin-provisioning<br /> suites for delete and suspend and no regressions were observed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occur<br /> <br /> scsi_execute_cmd() function can return both negative (linux codes) and<br /> positive (scsi_cmnd result field) error codes.<br /> <br /> Currently the driver just passes error codes of scsi_execute_cmd() to<br /> hwmon core, which is incorrect because hwmon only checks for negative<br /> error codes. This leads to hwmon reporting uninitialized data to<br /> userspace in case of SCSI errors (for example if the disk drive was<br /> disconnected).<br /> <br /> This patch checks scsi_execute_cmd() output and returns -EIO if it&amp;#39;s<br /> error code is positive.<br /> <br /> [groeck: Avoid inline variable declaration for portability]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Replace rq_lock() to raw_spin_rq_lock() in scx_ops_bypass()<br /> <br /> scx_ops_bypass() iterates all CPUs to re-enqueue all the scx tasks.<br /> For each CPU, it acquires a lock using rq_lock() regardless of whether<br /> a CPU is offline or the CPU is currently running a task in a higher<br /> scheduler class (e.g., deadline). The rq_lock() is supposed to be used<br /> for online CPUs, and the use of rq_lock() may trigger an unnecessary<br /> warning in rq_pin_lock(). Therefore, replace rq_lock() to<br /> raw_spin_rq_lock() in scx_ops_bypass().<br /> <br /> Without this change, we observe the following warning:<br /> <br /> ===== START =====<br /> [ 6.615205] rq-&gt;balance_callback &amp;&amp; rq-&gt;balance_callback != &amp;balance_push_callback<br /> [ 6.615208] WARNING: CPU: 2 PID: 0 at kernel/sched/sched.h:1730 __schedule+0x1130/0x1c90<br /> ===== END =====

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: avoid NULL pointer dereference if no valid extent tree<br /> <br /> [BUG]<br /> Syzbot reported a crash with the following call trace:<br /> <br /> BTRFS info (device loop0): scrub: started on devid 1<br /> BUG: kernel NULL pointer dereference, address: 0000000000000208<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G O 6.13.0-rc4-custom+ #206<br /> Tainted: [O]=OOT_MODULE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022<br /> RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs]<br /> Call Trace:<br /> <br /> scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs]<br /> scrub_simple_mirror+0x175/0x260 [btrfs]<br /> scrub_stripe+0x5d4/0x6c0 [btrfs]<br /> scrub_chunk+0xbb/0x170 [btrfs]<br /> scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs]<br /> btrfs_scrub_dev+0x240/0x600 [btrfs]<br /> btrfs_ioctl+0x1dc8/0x2fa0 [btrfs]<br /> ? do_sys_openat2+0xa5/0xf0<br /> __x64_sys_ioctl+0x97/0xc0<br /> do_syscall_64+0x4f/0x120<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> <br /> [CAUSE]<br /> The reproducer is using a corrupted image where extent tree root is<br /> corrupted, thus forcing to use "rescue=all,ro" mount option to mount the<br /> image.<br /> <br /> Then it triggered a scrub, but since scrub relies on extent tree to find<br /> where the data/metadata extents are, scrub_find_fill_first_stripe()<br /> relies on an non-empty extent root.<br /> <br /> But unfortunately scrub_find_fill_first_stripe() doesn&amp;#39;t really expect<br /> an NULL pointer for extent root, it use extent_root to grab fs_info and<br /> triggered a NULL pointer dereference.<br /> <br /> [FIX]<br /> Add an extra check for a valid extent root at the beginning of<br /> scrub_find_fill_first_stripe().<br /> <br /> The new error path is introduced by 42437a6386ff ("btrfs: introduce<br /> mount option rescue=ignorebadroots"), but that&amp;#39;s pretty old, and later<br /> commit b979547513ff ("btrfs: scrub: introduce helper to find and fill<br /> sector info for a scrub_stripe") changed how we do scrub.<br /> <br /> So for kernels older than 6.6, the fix will need manual backport.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdev: prevent accessing NAPI instances from another namespace<br /> <br /> The NAPI IDs were not fully exposed to user space prior to the netlink<br /> API, so they were never namespaced. The netlink API must ensure that<br /> at the very least NAPI instance belongs to the same netns as the owner<br /> of the genl sock.<br /> <br /> napi_by_id() can become static now, but it needs to move because of<br /> dev_get_by_napi_id().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: virtuser: fix missing lookup table cleanups<br /> <br /> When a virtuser device is created via configfs and the probe fails due<br /> to an incorrect lookup table, the table is not removed. This prevents<br /> subsequent probe attempts from succeeding, even if the issue is<br /> corrected, unless the device is released. Additionally, cleanup is also<br /> needed in the less likely case of platform_device_register_full()<br /> failure.<br /> <br /> Besides, a consistent memory leak in lookup_table-&gt;dev_id was spotted<br /> using kmemleak by toggling the live state between 0 and 1 with a correct<br /> lookup table.<br /> <br /> Introduce gpio_virtuser_remove_lookup_table() as the counterpart to the<br /> existing gpio_virtuser_make_lookup_table() and call it from all<br /> necessary points to ensure proper cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: dwmac-tegra: Read iommu stream id from device tree<br /> <br /> Nvidia&amp;#39;s Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to be<br /> written to the MGBE_WRAP_AXI_ASID0_CTRL register.<br /> <br /> The current driver is hard coded to use MGBE0&amp;#39;s SID for all controllers.<br /> This causes softirq time outs and kernel panics when using controllers<br /> other than MGBE0.<br /> <br /> Example dmesg errors when an ethernet cable is connected to MGBE1:<br /> <br /> [ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx<br /> [ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms<br /> [ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter.<br /> [ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0<br /> [ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171)<br /> [ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features<br /> [ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported<br /> [ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock<br /> [ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode<br /> [ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx<br /> [ 181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:<br /> [ 181.921404] rcu: 7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337<br /> [ 181.921684] rcu: (detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8)<br /> [ 181.921878] Sending NMI from CPU 4 to CPUs 7:<br /> [ 181.921886] NMI backtrace for cpu 7<br /> [ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6<br /> [ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024<br /> [ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 181.922847] pc : handle_softirqs+0x98/0x368<br /> [ 181.922978] lr : __do_softirq+0x18/0x20<br /> [ 181.923095] sp : ffff80008003bf50<br /> [ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000<br /> [ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0<br /> [ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70<br /> [ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000<br /> [ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000<br /> [ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d<br /> [ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160<br /> [ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74<br /> [ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1<br /> [ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000<br /> [ 181.967591] Call trace:<br /> [ 181.970043] handle_softirqs+0x98/0x368 (P)<br /> [ 181.974240] __do_softirq+0x18/0x20<br /> [ 181.977743] ____do_softirq+0x14/0x28<br /> [ 181.981415] call_on_irq_stack+0x24/0x30<br /> [ 181.985180] do_softirq_own_stack+0x20/0x30<br /> [ 181.989379] __irq_exit_rcu+0x114/0x140<br /> [ 181.993142] irq_exit_rcu+0x14/0x28<br /> [ 181.996816] el1_interrupt+0x44/0xb8<br /> [ 182.000316] el1h_64_irq_handler+0x14/0x20<br /> [ 182.004343] el1h_64_irq+0x80/0x88<br /> [ 182.007755] cpuidle_enter_state+0xc4/0x4a8 (P)<br /> [ 182.012305] cpuidle_enter+0x3c/0x58<br /> [ 182.015980] cpuidle_idle_call+0x128/0x1c0<br /> [ 182.020005] do_idle+0xe0/0xf0<br /> [ 182.023155] cpu_startup_entry+0x3c/0x48<br /> [ 182.026917] secondary_start_kernel+0xdc/0x120<br /> [ 182.031379] __secondary_switched+0x74/0x78<br /> [ 212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/.<br /> [ 212.985935] rcu: blocking rcu_node structures (internal RCU debug):<br /> [ 212.992758] Sending NMI from CPU 0 to CPUs 7:<br /> [ 212.998539] NMI backtrace for cpu 7<br /> [ 213.004304] CPU: 7 UID: 0 PI<br /> ---truncated---