Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: bridge: replace physindev with physinif in nf_bridge_info<br /> <br /> An skb can be added to a neigh-&gt;arp_queue while waiting for an arp<br /> reply. Where original skb&amp;#39;s skb-&gt;dev can be different to neigh&amp;#39;s<br /> neigh-&gt;dev. For instance in case of bridging dnated skb from one veth to<br /> another, the skb would be added to a neigh-&gt;arp_queue of the bridge.<br /> <br /> As skb-&gt;dev can be reset back to nf_bridge-&gt;physindev and used, and as<br /> there is no explicit mechanism that prevents this physindev from been<br /> freed under us (for instance neigh_flush_dev doesn&amp;#39;t cleanup skbs from<br /> different device&amp;#39;s neigh queue) we can crash on e.g. this stack:<br /> <br /> arp_process<br /> neigh_update<br /> skb = __skb_dequeue(&amp;neigh-&gt;arp_queue)<br /> neigh_resolve_output(..., skb)<br /> ...<br /> br_nf_dev_xmit<br /> br_nf_pre_routing_finish_bridge_slow<br /> skb-&gt;dev = nf_bridge-&gt;physindev<br /> br_handle_frame_finish<br /> <br /> Let&amp;#39;s use plain ifindex instead of net_device link. To peek into the<br /> original net_device we will use dev_get_by_index_rcu(). Thus either we<br /> get device and are safe to use it or we don&amp;#39;t get it and drop skb.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()<br /> <br /> subflow_finish_connect() uses four fields (backup, join_id, thmac, none)<br /> that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set<br /> in mptcp_parse_option()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tls, fix WARNIING in __sk_msg_free<br /> <br /> A splice with MSG_SPLICE_PAGES will cause tls code to use the<br /> tls_sw_sendmsg_splice path in the TLS sendmsg code to move the user<br /> provided pages from the msg into the msg_pl. This will loop over the<br /> msg until msg_pl is full, checked by sk_msg_full(msg_pl). The user<br /> can also set the MORE flag to hint stack to delay sending until receiving<br /> more pages and ideally a full buffer.<br /> <br /> If the user adds more pages to the msg than can fit in the msg_pl<br /> scatterlist (MAX_MSG_FRAGS) we should ignore the MORE flag and send<br /> the buffer anyways.<br /> <br /> What actually happens though is we abort the msg to msg_pl scatterlist<br /> setup and then because we forget to set &amp;#39;full record&amp;#39; indicating we<br /> can no longer consume data without a send we fallthrough to the &amp;#39;continue&amp;#39;<br /> path which will check if msg_data_left(msg) has more bytes to send and<br /> then attempts to fit them in the already full msg_pl. Then next<br /> iteration of sender doing send will encounter a full msg_pl and throw<br /> the warning in the syzbot report.<br /> <br /> To fix simply check if we have a full_record in splice code path and<br /> if not send the msg regardless of MORE flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: sof-common: Add NULL check for normal_link string<br /> <br /> It&amp;#39;s not granted that all entries of struct sof_conn_stream declare<br /> a `normal_link` (a non-SOF, direct link) string, and this is the case<br /> for SoCs that support only SOF paths (hence do not support both direct<br /> and SOF usecases).<br /> <br /> For example, in the case of MT8188 there is no normal_link string in<br /> any of the sof_conn_stream entries and there will be more drivers<br /> doing that in the future.<br /> <br /> To avoid possible NULL pointer KPs, add a NULL check for `normal_link`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Use device rbtree in iopf reporting path<br /> <br /> The existing I/O page fault handler currently locates the PCI device by<br /> calling pci_get_domain_bus_and_slot(). This function searches the list<br /> of all PCI devices until the desired device is found. To improve lookup<br /> efficiency, replace it with device_rbtree_find() to search the device<br /> within the probed device rbtree.<br /> <br /> The I/O page fault is initiated by the device, which does not have any<br /> synchronization mechanism with the software to ensure that the device<br /> stays in the probed device tree. Theoretically, a device could be released<br /> by the IOMMU subsystem after device_rbtree_find() and before<br /> iopf_get_dev_fault_param(), which would cause a use-after-free problem.<br /> <br /> Add a mutex to synchronize the I/O page fault reporting path and the IOMMU<br /> release device path. This lock doesn&amp;#39;t introduce any performance overhead,<br /> as the conflict between I/O page fault reporting and device releasing is<br /> very rare.