Vulnerabilities

Improper input validation in PAM JIT elevation feature in Devolutions Server 2024.1.11.0 and earlier allows an authenticated user with access to the PAM JIT elevation feature to manipulate the LDAP filter query via a specially crafted request.

Dell BIOS contains an Improper Input Validation vulnerability. A local authenticated malicious user with admin privileges could potentially exploit this vulnerability, leading to arbitrary code execution.

The com.solarized.firedown (aka Solarized FireDown Browser & Downloader) application 1.0.76 for Android allows a remote attacker to execute arbitrary JavaScript code via a crafted intent. com.solarized.firedown.IntentActivity uses a WebView component to display web content and doesn't adequately sanitize the URI or any extra data passed in the intent by any installed application (with no permissions).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> icmp: prevent possible NULL dereferences from icmp_build_probe()<br /> <br /> First problem is a double call to __in_dev_get_rcu(), because<br /> the second one could return NULL.<br /> <br /> if (__in_dev_get_rcu(dev) &amp;&amp; __in_dev_get_rcu(dev)-&gt;ifa_list)<br /> <br /> Second problem is a read from dev-&gt;ip6_ptr with no NULL check:<br /> <br /> if (!list_empty(&amp;rcu_dereference(dev-&gt;ip6_ptr)-&gt;addr_list))<br /> <br /> Use the correct RCU API to fix these.<br /> <br /> v2: add missing include

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bcmasp: fix memory leak when bringing down interface<br /> <br /> When bringing down the TX rings we flush the rings but forget to<br /> reclaimed the flushed packets. This leads to a memory leak since we<br /> do not free the dma mapped buffers. This also leads to tx control<br /> block corruption when bringing down the interface for power<br /> management.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix module reference leakage from bdev_open_by_dev error path<br /> <br /> At the time bdev_may_open() is called, module reference is grabbed<br /> already, hence module reference should be released if bdev_may_open()<br /> failed.<br /> <br /> This problem is found by code review.

A vulnerability has been found in SourceCodester Gas Agency Management System 1.0 and classified as critical. This vulnerability affects unknown code of the file edituser.php. The manipulation of the argument id leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-264748.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work<br /> <br /> The rehash delayed work is rescheduled with a delay if the number of<br /> credits at end of the work is not negative as supposedly it means that<br /> the migration ended. Otherwise, it is rescheduled immediately.<br /> <br /> After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during<br /> rehash" the above is no longer accurate as a non-negative number of<br /> credits is no longer indicative of the migration being done. It can also<br /> happen if the work encountered an error in which case the migration will<br /> resume the next time the work is scheduled.<br /> <br /> The significance of the above is that it is possible for the work to be<br /> pending and associated with hints that were allocated when the migration<br /> started. This leads to the hints being leaked [1] when the work is<br /> canceled while pending as part of ACL region dismantle.<br /> <br /> Fix by freeing the hints if hints are associated with a work that was<br /> canceled while pending.<br /> <br /> Blame the original commit since the reliance on not having a pending<br /> work associated with hints is fragile.<br /> <br /> [1]<br /> unreferenced object 0xffff88810e7c3000 (size 256):<br /> comm "kworker/0:16", pid 176, jiffies 4295460353<br /> hex dump (first 32 bytes):<br /> 00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a.......<br /> 00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@...........<br /> backtrace (crc 2544ddb9):<br /> [] kmalloc_trace+0x23f/0x2a0<br /> [] objagg_hints_get+0x42/0x390<br /> [] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400<br /> [] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160<br /> [] process_one_work+0x59c/0xf20<br /> [] worker_thread+0x799/0x12c0<br /> [] kthread+0x246/0x300<br /> [] ret_from_fork+0x34/0x70<br /> [] ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix memory leak during rehash<br /> <br /> The rehash delayed work migrates filters from one region to another.<br /> This is done by iterating over all chunks (all the filters with the same<br /> priority) in the region and in each chunk iterating over all the<br /> filters.<br /> <br /> If the migration fails, the code tries to migrate the filters back to<br /> the old region. However, the rollback itself can also fail in which case<br /> another migration will be erroneously performed. Besides the fact that<br /> this ping pong is not a very good idea, it also creates a problem.<br /> <br /> Each virtual chunk references two chunks: The currently used one<br /> (&amp;#39;vchunk-&gt;chunk&amp;#39;) and a backup (&amp;#39;vchunk-&gt;chunk2&amp;#39;). During migration the<br /> first holds the chunk we want to migrate filters to and the second holds<br /> the chunk we are migrating filters from.<br /> <br /> The code currently assumes - but does not verify - that the backup chunk<br /> does not exist (NULL) if the currently used chunk does not reference the<br /> target region. This assumption breaks when we are trying to rollback a<br /> rollback, resulting in the backup chunk being overwritten and leaked<br /> [1].<br /> <br /> Fix by not rolling back a failed rollback and add a warning to avoid<br /> future cases.<br /> <br /> [1]<br /> WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20<br /> Modules linked in:<br /> CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14<br /> Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019<br /> Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work<br /> RIP: 0010:parman_destroy+0x17/0x20<br /> [...]<br /> Call Trace:<br /> <br /> mlxsw_sp_acl_atcam_region_fini+0x19/0x60<br /> mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470<br /> process_one_work+0x151/0x370<br /> worker_thread+0x2cb/0x3e0<br /> kthread+0xd0/0x100<br /> ret_from_fork+0x34/0x50<br /> ret_from_fork_asm+0x1a/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash<br /> <br /> The rehash delayed work migrates filters from one region to another<br /> according to the number of available credits.<br /> <br /> The migrated from region is destroyed at the end of the work if the<br /> number of credits is non-negative as the assumption is that this is<br /> indicative of migration being complete. This assumption is incorrect as<br /> a non-negative number of credits can also be the result of a failed<br /> migration.<br /> <br /> The destruction of a region that still has filters referencing it can<br /> result in a use-after-free [1].<br /> <br /> Fix by not destroying the region if migration failed.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230<br /> Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858<br /> <br /> CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5<br /> Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019<br /> Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xc6/0x120<br /> print_report+0xce/0x670<br /> kasan_report+0xd7/0x110<br /> mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230<br /> mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70<br /> mlxsw_sp_acl_atcam_entry_del+0x81/0x210<br /> mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300<br /> process_one_work+0x8eb/0x19b0<br /> worker_thread+0x6c9/0xf70<br /> kthread+0x2c9/0x3b0<br /> ret_from_fork+0x4d/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 174:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> __kmalloc+0x19c/0x360<br /> mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300<br /> process_one_work+0x8eb/0x19b0<br /> worker_thread+0x6c9/0xf70<br /> kthread+0x2c9/0x3b0<br /> ret_from_fork+0x4d/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Freed by task 7:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> poison_slab_object+0x102/0x170<br /> __kasan_slab_free+0x14/0x30<br /> kfree+0xc1/0x290<br /> mlxsw_sp_acl_tcam_region_destroy+0x272/0x310<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300<br /> process_one_work+0x8eb/0x19b0<br /> worker_thread+0x6c9/0xf70<br /> kthread+0x2c9/0x3b0<br /> ret_from_fork+0x4d/0x80<br /> ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update<br /> <br /> The rule activity update delayed work periodically traverses the list of<br /> configured rules and queries their activity from the device.<br /> <br /> As part of this task it accesses the entry pointed by &amp;#39;ventry-&gt;entry&amp;#39;,<br /> but this entry can be changed concurrently by the rehash delayed work,<br /> leading to a use-after-free [1].<br /> <br /> Fix by closing the race and perform the activity query under the<br /> &amp;#39;vregion-&gt;lock&amp;#39; mutex.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140<br /> Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181<br /> <br /> CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2<br /> Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019<br /> Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xc6/0x120<br /> print_report+0xce/0x670<br /> kasan_report+0xd7/0x110<br /> mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140<br /> mlxsw_sp_acl_rule_activity_update_work+0x219/0x400<br /> process_one_work+0x8eb/0x19b0<br /> worker_thread+0x6c9/0xf70<br /> kthread+0x2c9/0x3b0<br /> ret_from_fork+0x4d/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 1039:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> __kmalloc+0x19c/0x360<br /> mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0<br /> mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300<br /> process_one_work+0x8eb/0x19b0<br /> worker_thread+0x6c9/0xf70<br /> kthread+0x2c9/0x3b0<br /> ret_from_fork+0x4d/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Freed by task 1039:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> poison_slab_object+0x102/0x170<br /> __kasan_slab_free+0x14/0x30<br /> kfree+0xc1/0x290<br /> mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300<br /> process_one_work+0x8eb/0x19b0<br /> worker_thread+0x6c9/0xf70<br /> kthread+0x2c9/0x3b0<br /> ret_from_fork+0x4d/0x80<br /> ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: mediatek: Fix double free of skb in coredump<br /> <br /> hci_devcd_append() would free the skb on error so the caller don&amp;#39;t<br /> have to free it again otherwise it would cause the double free of skb.<br /> <br /> Reported-by : Dan Carpenter