Vulnerabilities

In the mintupload package through 4.2.0 for Linux Mint, service-name mishandling leads to command injection via shell metacharacters in check_connection, drop_data_received_cb, and Service.remove. A user can modify a service name in a ~/.linuxmint/mintUpload/services/service file.

A vulnerability was found in SourceCodester Simple Inventory System 1.0. It has been declared as critical. This vulnerability affects unknown code of the file updateproduct.php. The manipulation of the argument ITEM 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-265084.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dyndbg: fix old BUG_ON in &gt;control parser<br /> <br /> Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn&amp;#39;t<br /> really look), lets make sure by removing it, doing pr_err and return<br /> -EINVAL instead.

A vulnerability was found in SourceCodester Simple Inventory System 1.0. It has been classified as critical. This affects an unknown part of the file tableedit.php. The manipulation of the argument from/to leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-265083.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()<br /> <br /> Syzkaller hit &amp;#39;WARNING in dg_dispatch_as_host&amp;#39; bug.<br /> <br /> memcpy: detected field-spanning write (size 56) of single field "&amp;dg_info-&gt;msg"<br /> at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24)<br /> <br /> WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237<br /> dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237<br /> <br /> Some code commentry, based on my understanding:<br /> <br /> 544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)-&gt;payload_size)<br /> /// This is 24 + payload_size<br /> <br /> memcpy(&amp;dg_info-&gt;msg, dg, dg_size);<br /> Destination = dg_info-&gt;msg ---&gt; this is a 24 byte<br /> structure(struct vmci_datagram)<br /> Source = dg --&gt; this is a 24 byte structure (struct vmci_datagram)<br /> Size = dg_size = 24 + payload_size<br /> <br /> {payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32.<br /> <br /> 35 struct delayed_datagram_info {<br /> 36 struct datagram_entry *entry;<br /> 37 struct work_struct work;<br /> 38 bool in_dg_host_queue;<br /> 39 /* msg and msg_payload must be together. */<br /> 40 struct vmci_datagram msg;<br /> 41 u8 msg_payload[];<br /> 42 };<br /> <br /> So those extra bytes of payload are copied into msg_payload[], a run time<br /> warning is seen while fuzzing with Syzkaller.<br /> <br /> One possible way to fix the warning is to split the memcpy() into<br /> two parts -- one -- direct assignment of msg and second taking care of payload.<br /> <br /> Gustavo quoted:<br /> "Under FORTIFY_SOURCE we should not copy data across multiple members<br /> in a structure."

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: phy_device: Prevent nullptr exceptions on ISR<br /> <br /> If phydev-&gt;irq is set unconditionally, check<br /> for valid interrupt handler or fall back to polling mode to prevent<br /> nullptr exceptions in interrupt service routine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: fix null pointer access when abort scan<br /> <br /> During cancel scan we might use vif that weren&amp;#39;t scanning.<br /> Fix this by using the actual scanning vif.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()<br /> <br /> The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an<br /> unsuccessful status. In such cases, the elsiocb is not issued, the<br /> completion is not called, and thus the elsiocb resource is leaked.<br /> <br /> Check return value after calling lpfc_sli4_resume_rpi() and conditionally<br /> release the elsiocb resource.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Skip do PCI error slot reset during RAS recovery<br /> <br /> Why:<br /> The PCI error slot reset maybe triggered after inject ue to UMC multi times, this<br /> caused system hang.<br /> [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume<br /> [ 557.373718] [drm] PCIE GART of 512M enabled.<br /> [ 557.373722] [drm] PTB located at 0x0000031FED700000<br /> [ 557.373788] [drm] VRAM is lost due to GPU reset!<br /> [ 557.373789] [drm] PSP is resuming...<br /> [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset<br /> [ 557.547067] [drm] PCI error: detected callback, state(1)!!<br /> [ 557.547069] [drm] No support for XGMI hive yet...<br /> [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter<br /> [ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations<br /> [ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered<br /> [ 557.610492] [drm] PCI error: slot reset callback!!<br /> ...<br /> [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!<br /> [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!<br /> [ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI<br /> [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu<br /> [ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023<br /> [ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]<br /> [ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]<br /> [ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00<br /> [ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202<br /> [ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0<br /> [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010<br /> [ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08<br /> [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000<br /> [ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000<br /> [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000<br /> [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0<br /> [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> [ 560.843444] PKRU: 55555554<br /> [ 560.846480] Call Trace:<br /> [ 560.849225] <br /> [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea<br /> [ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea<br /> [ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]<br /> [ 560.867778] ? show_regs.part.0+0x23/0x29<br /> [ 560.872293] ? __die_body.cold+0x8/0xd<br /> [ 560.876502] ? die_addr+0x3e/0x60<br /> [ 560.880238] ? exc_general_protection+0x1c5/0x410<br /> [ 560.885532] ? asm_exc_general_protection+0x27/0x30<br /> [ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]<br /> [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]<br /> [ 560.904520] process_one_work+0x228/0x3d0<br /> How:<br /> In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected<br /> all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: don&amp;#39;t check if plane-&gt;state-&gt;fb == state-&gt;fb<br /> <br /> Currently, when using non-blocking commits, we can see the following<br /> kernel warning:<br /> <br /> [ 110.908514] ------------[ cut here ]------------<br /> [ 110.908529] refcount_t: underflow; use-after-free.<br /> [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0<br /> [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6<br /> [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32<br /> [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)<br /> [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0<br /> [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0<br /> [ 110.909170] sp : ffffffc00913b9c0<br /> [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60<br /> [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480<br /> [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78<br /> [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000<br /> [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004<br /> [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003<br /> [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00<br /> [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572<br /> [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000<br /> [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001<br /> [ 110.909434] Call trace:<br /> [ 110.909441] refcount_dec_not_one+0xb8/0xc0<br /> [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]<br /> [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4]<br /> [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]<br /> [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4]<br /> [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper]<br /> [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]<br /> [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm]<br /> [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm]<br /> [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm]<br /> [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm]<br /> [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4<br /> [ 110.914873] invoke_syscall+0x4c/0x114<br /> [ 110.914897] el0_svc_common+0xd0/0x118<br /> [ 110.914917] do_el0_svc+0x38/0xd0<br /> [ 110.914936] el0_svc+0x30/0x8c<br /> [ 110.914958] el0t_64_sync_handler+0x84/0xf0<br /> [ 110.914979] el0t_64_sync+0x18c/0x190<br /> [ 110.914996] ---[ end trace 0000000000000000 ]---<br /> <br /> This happens because, although `prepare_fb` and `cleanup_fb` are<br /> perfectly balanced, we cannot guarantee consistency in the check<br /> plane-&gt;state-&gt;fb == state-&gt;fb. This means that sometimes we can increase<br /> the refcount in `prepare_fb` and don&amp;#39;t decrease it in `cleanup_fb`. The<br /> opposite can also be true.<br /> <br /> In fact, the struct drm_plane .state shouldn&amp;#39;t be accessed directly<br /> but instead, the `drm_atomic_get_new_plane_state()` helper function should<br /> be used. So, we could stick to this check, but using<br /> `drm_atomic_get_new_plane_state()`. But actually, this check is not re<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btintel: Fix null ptr deref in btintel_read_version<br /> <br /> If hci_cmd_sync_complete() is triggered and skb is NULL, then<br /> hdev-&gt;req_skb is NULL, which will cause this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list()<br /> <br /> Many syzbot reports show extreme rtnl pressure, and many of them hint<br /> that smc acquires rtnl in netns creation for no good reason [1]<br /> <br /> This patch returns early from smc_pnet_net_init()<br /> if there is no netdevice yet.<br /> <br /> I am not even sure why smc_pnet_create_pnetids_list() even exists,<br /> because smc_pnet_netdev_event() is also calling<br /> smc_pnet_add_base_pnetid() when handling NETDEV_UP event.<br /> <br /> [1] extract of typical syzbot reports<br /> <br /> 2 locks held by syz-executor.3/12252:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.4/12253:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.1/12257:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.2/12261:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.0/12265:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.3/12268:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.4/12271:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.1/12274:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.2/12280:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878