Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost/vsock: Use kvmalloc/kvfree for larger packets.<br /> <br /> When copying a large file over sftp over vsock, data size is usually 32kB,<br /> and kmalloc seems to fail to try to allocate 32 32kB regions.<br /> <br /> vhost-5837: page allocation failure: order:4, mode:0x24040c0<br /> Call Trace:<br /> [] dump_stack+0x97/0xdb<br /> [] warn_alloc_failed+0x10f/0x138<br /> [] ? __alloc_pages_direct_compact+0x38/0xc8<br /> [] __alloc_pages_nodemask+0x84c/0x90d<br /> [] alloc_kmem_pages+0x17/0x19<br /> [] kmalloc_order_trace+0x2b/0xdb<br /> [] __kmalloc+0x177/0x1f7<br /> [] ? copy_from_iter+0x8d/0x31d<br /> [] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock]<br /> [] vhost_worker+0xf7/0x157 [vhost]<br /> [] kthread+0xfd/0x105<br /> [] ? vhost_dev_set_owner+0x22e/0x22e [vhost]<br /> [] ? flush_kthread_worker+0xf3/0xf3<br /> [] ret_from_fork+0x4e/0x80<br /> [] ? flush_kthread_worker+0xf3/0xf3<br /> <br /> Work around by doing kvmalloc instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Validate BOOT record_size<br /> <br /> When the NTFS BOOT record_size field record_bits calculation through blksize_bits() assumes<br /> the size always &gt; 256, which could lead to NPD while mounting a<br /> malformed NTFS image.<br /> <br /> [ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158<br /> [ 318.675682] #PF: supervisor read access in kernel mode<br /> [ 318.675869] #PF: error_code(0x0000) - not-present page<br /> [ 318.676246] PGD 0 P4D 0<br /> [ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5<br /> [ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 318.678136] RIP: 0010:ni_find_attr+0x2d/0x1c0<br /> [ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180<br /> [ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246<br /> [ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080<br /> [ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> [ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080<br /> [ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000<br /> [ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000<br /> [ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0<br /> [ 318.685623] Call Trace:<br /> [ 318.686607] <br /> [ 318.686872] ? ntfs_alloc_inode+0x1a/0x60<br /> [ 318.687235] attr_load_runs_vcn+0x2b/0xa0<br /> [ 318.687468] mi_read+0xbb/0x250<br /> [ 318.687576] ntfs_iget5+0x114/0xd90<br /> [ 318.687750] ntfs_fill_super+0x588/0x11b0<br /> [ 318.687953] ? put_ntfs+0x130/0x130<br /> [ 318.688065] ? snprintf+0x49/0x70<br /> [ 318.688164] ? put_ntfs+0x130/0x130<br /> [ 318.688256] get_tree_bdev+0x16a/0x260<br /> [ 318.688407] vfs_get_tree+0x20/0xb0<br /> [ 318.688519] path_mount+0x2dc/0x9b0<br /> [ 318.688877] do_mount+0x74/0x90<br /> [ 318.689142] __x64_sys_mount+0x89/0xd0<br /> [ 318.689636] do_syscall_64+0x3b/0x90<br /> [ 318.689998] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 318.690318] RIP: 0033:0x7fd9e133c48a<br /> [ 318.690687] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 318.691357] RSP: 002b:00007ffd374406c8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5<br /> [ 318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX: 00007fd9e133c48a<br /> [ 318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0<br /> [ 318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020<br /> [ 318.692349] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564d0b0596a0<br /> [ 318.692673] R13: 0000564d0b051280 R14: 0000000000000000 R15: 00000000ffffffff<br /> [ 318.693007] <br /> [ 318.693271] Modules linked in:<br /> [ 318.693614] CR2: 0000000000000158<br /> [ 318.694446] ---[ end trace 0000000000000000 ]---<br /> [ 318.694779] RIP: 0010:ni_find_attr+0x2d/0x1c0<br /> [ 318.694952] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180<br /> [ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246<br /> [ 318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080<br /> [ 318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 318.699286] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> [ 318.699795] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080<br /> [ 318.700236] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000<br /> [ 318.700973] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000<br /> [<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpasim: fix memory leak when freeing IOTLBs<br /> <br /> After commit bda324fd037a ("vdpasim: control virtqueue support"),<br /> vdpasim-&gt;iommu became an array of IOTLB, so we should clean the<br /> mappings of each free one by one instead of just deleting the ranges<br /> in the first IOTLB which may leak maps.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: socfpga: Fix memory leak in socfpga_gate_init()<br /> <br /> Free @socfpga_clk and @ops on the error path to avoid memory leak issue.

feiskyer mcp-kubernetes-server through 0.1.11 does not consider chained commands in the implementation of --disable-write and --disable-delete, e.g., it allows a "kubectl version; kubectl delete pod" command because the first word (i.e., "version") is not a write or delete operation.

feiskyer mcp-kubernetes-server through 0.1.11 allows OS command injection, even in read-only mode, via /mcp/kubectl because shell=True is used. NOTE: this is unrelated to mcp-server-kubernetes and CVE-2025-53355.

A flaw has been found in Campcodes Online Job Finder System 1.0. This affects an unknown function of the file /index.php?q=result&amp;searchfor=bycompany. This manipulation of the argument Search causes sql injection. The attack can be initiated remotely. The exploit has been published and may be used.

An issue was discovered in the methods push.lite.avtech.com.AvtechLib.GetHttpsResponse and push.lite.avtech.com.Push_HttpService.getNewHttpClient in AVTECH EagleEyes 2.0.0. The methods set ALLOW_ALL_HOSTNAME_VERIFIER, bypassing domain validation.

An issue was discovered in the method push.lite.avtech.com.AvtechLib.GetHttpsResponse in AVTECH EagleEyes Lite 2.0.0, the GetHttpsResponse method transmits sensitive information - including internal server URLs, account IDs, passwords, and device tokens - as plaintext query parameters over HTTPS

An issue was discovered in the method push.lite.avtech.com.MySSLSocketFactoryNew.checkServerTrusted in AVTECH EagleEyes 2.0.0. The custom X509TrustManager used in checkServerTrusted only checks the certificate&amp;#39;s expiration date, skipping proper TLS chain validation.

A Cross-Site Request Forgery (CSRF) vulnerability was identified in the Profile Page of the PHPGurukul Student-Result-Management-System-Using-PHP-V2.0. This flaw allows an attacker to trick authenticated users into unintentionally modifying their account details. By crafting a malicious HTML page, an attacker can submit unauthorized requests to the vulnerable endpoint: /create-class.php.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: uhci: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.