Vulnerabilities

nanoMODBUS through v1.23.0 contains an out-of-bounds write in the Modbus client-side recv_read_device_identification_res function (FC 0x2B/MEI 0x0E, Read Device Identification) in nanomodbus.c. The server-supplied object_length field (0-246) is validated only against the remaining PDU size (res_size_left) and is never validated against the caller-supplied buffers_length parameter.

nanoMODBUS through v1.23.0 contains an out-of-bounds stack read leading to a wild-pointer write in nmbs_read_device_identification_basic / recv_read_device_identification_res in nanomodbus.c. A fixed 3-element stack array order[3] = {0,1,2} maps object IDs to buffer indices. The server-supplied object_id field (0-255, read directly from the wire) is used without any bounds check as buf_index = order[object_id].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix a use-after-free problem in rxe_mmap<br /> <br /> rxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list<br /> and releases pending_lock while the struct&amp;#39;s kref is still at 1:<br /> <br /> list_del_init(&amp;ip-&gt;pending_mmaps);<br /> spin_unlock_bh(&amp;rxe-&gt;pending_lock); /* ref == 1, no lock held */<br /> ret = remap_vmalloc_range(vma, ip-&gt;obj, 0); /* walks PTEs */<br /> [...]<br /> rxe_vma_open(vma); /* kref_get, ref → 2 */<br /> remap_vmalloc_range_partial() walks PTEs without any lock.<br /> <br /> A concurrent DESTROY_CQ ioctl on another CPU calls:<br /> <br /> kref_put(&amp;q-&gt;ip-&gt;ref, rxe_mmap_release) /* ref 1→0 */<br /> vfree(ip-&gt;obj) /* clears vmalloc PTEs mid-walk */<br /> kfree(ip) /* frees rxe_mmap_info */<br /> <br /> This yields:<br /> <br /> 1. Kernel crash, vmalloc_to_page() returns NULL when vfree wins the<br /> per-PTE race -&gt; vm_insert_page(NULL) → GPF in validate_page_before_insert<br /> <br /> 2. Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears<br /> it. User VMA holds a PTE to a free&amp;#39;d page which might eventually get<br /> reallocated later by vmalloc which allows the attacker to get a clean<br /> page-level UAF.<br /> <br /> It is worth noting that even though a page-level UAF is possible given<br /> the strong primitive, it is statistically very difficult to achieve<br /> given the very short time window (after the last insert_page and before<br /> the kref_get).<br /> <br /> The call trace are as below:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 0 UID: 1000 PID: 413 Comm: poc Not tainted 7.0.0-rc5-dirty #28 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:validate_page_before_insert+0x32/0x300<br /> Code: e5 41 57 41 56 49 89 fe 41 55 41 54 53 48 89 f3 e8 93 b5 a3 ff 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 3c 02 00 0f 85 7b 02 00 00 4c 8b 63 08 31 ff 4d 89 e5 41 83 e5<br /> RSP: 0018:ffff88811b15f2f0 EFLAGS: 00000202<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008<br /> RBP: ffff88811b15f318 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881181eee00<br /> R13: 0000000000000000 R14: ffff8881181eee00 R15: ffff8881181eee20<br /> FS: 00007b1e000f76c0(0000) GS:ffff8884268e0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007b1e00a24ac0 CR3: 0000000116eb3000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> insert_page+0x8f/0x190<br /> ? __pfx_insert_page+0x10/0x10<br /> ? kasan_save_alloc_info+0x38/0x60<br /> vm_insert_page+0x2e7/0x400<br /> remap_vmalloc_range_partial+0x212/0x3e0<br /> remap_vmalloc_range+0x6e/0xb0<br /> ? __kasan_check_write+0x14/0x30<br /> rxe_mmap+0x2e9/0x5d0<br /> ib_uverbs_mmap+0x1ad/0x2c0<br /> __mmap_region+0x12c2/0x2ad0<br /> ? __pfx___mmap_region+0x10/0x10<br /> ? __sanitizer_cov_trace_switch+0x58/0xb0<br /> ? mas_prev_slot+0x360/0x39c0<br /> ? __sanitizer_cov_trace_switch+0x58/0xb0<br /> ? mas_next_slot+0x1e5b/0x2f40<br /> ? __sanitizer_cov_trace_cmp8+0x18/0x30<br /> ? unmapped_area_topdown+0x4dd/0x610<br /> ? kfree+0x1b1/0x440<br /> ? free_cpumask_var+0x16/0x30<br /> ? __kasan_slab_free+0x7d/0xa0<br /> ? __sanitizer_cov_trace_cmp8+0x18/0x30<br /> mmap_region+0x2e6/0x3c0<br /> do_mmap+0xa3e/0x12a0<br /> ? __pfx_do_mmap+0x10/0x10<br /> ? __kasan_check_write+0x14/0x30<br /> ? down_write_killable+0xba/0x160<br /> ? __pfx_down_write_killable+0x10/0x10<br /> ? __sanitizer_cov_trace_cmp4+0x16/0x30<br /> vm_mmap_pgoff+0x2d4/0x4a0<br /> ? __pfx_vm_mmap_pgoff+0x10/0x10<br /> ? fget+0x1bf/0x270<br /> ksys_mmap_pgoff+0x40c/0x690<br /> ? __sanitizer_cov_trace_const_cmp4+0x16/0x30<br /> ? __pfx_ksys_mmap_pgoff+0x10/0x10<br /> ? __kasan_check_write+0x14/0x30<br /> ? _raw_spin_trylock+0xbb/0x130<br /> ? __pfx__raw_spin_trylock+0x10/0x10<br /> __x64_sys_mmap+0x135/0x1e0<br /> x64_sys_c<br /> ---truncated---

The wp-downloadmanager WordPress plugin, in version 1.68.11 (also affecting the 6.9.4 release line), allows an admin-privileged user (current_user_can(&amp;#39;manage_downloads&amp;#39;)) to upload arbitrary files via download-add.php with no extension or MIME-type validation of any kind - no wp_check_filetype_and_ext, no validate_file, and no extension blocklist exist anywhere in the upload handler.

Firefly III&amp;#39;s webhook URL validator (IsValidWebhookUrl.php) filters most private/reserved IPv4 ranges but contains an explicit early-return that allows any resolved address in 127.0.0.0/8, permitting an authenticated user (with webhooks enabled, which is off by default) to configure a webhook targeting loopback services on the server.

Akaunting&amp;#39;s shared download route (app/Http/Controllers/Common/Uploads.php::download, reachable at uploads/{id}/download behind only generic auth middleware) fetched the requested Media record by ID with no verification that it belonged to the requesting portal customer&amp;#39;s own company, allowing any authenticated portal customer to download any other company&amp;#39;s uploaded files by guessing or enumerating media IDs.

toner-management&amp;#39;s admin state-changing handlers (add.php, edit.php, delete.php under admin/toners, admin/toner-brands, admin/printers, and related admin subdirectories) executed INSERT/UPDATE/DELETE database operations with no authentication or authorization check, while access control was enforced only in listing views.

Crater&amp;#39;s NotePolicy checks only a blanket Bouncer ability (manage-all-notes / view-all-notes) with no company-ownership comparison, unlike InvoicePolicy and other sibling policies which additionally verify -&gt;hasCompany(-&gt;company_id). Any authenticated user of one company can read, edit, or delete another company&amp;#39;s notes by ID.

The backmeup npm package assembles shell command strings by directly concatenating its option values (name, source, destination, filter) - e.g. cmd = "mkdir -p " + path.join(info.destination, info.name) + "; " - and executes the resulting string through a shell via ssh2-exec (locally via child_process, or remotely via SSH when an ssh handle is supplied), rather than using execFile/spawn with an argument array.

Paperless-ngx&amp;#39;s MailAccountViewSet.test action, when called with an existing account&amp;#39;s ID and a masked password field, reuses the stored password, account_type, refresh_token, and expiration from that existing account while allowing the caller to supply a different imap_server, imap_port, and imap_security in the same request.

Pixelfed&amp;#39;s SearchController (behind the auth middleware) accepts a URL via its remote-search parameters and fetches it server-side through ActivityPubFetchService, whose validateUrl only blocks the literal hosts 127.0.0.1, localhost, and ::1 and requires https, without checking the resolved IP against private, internal, or link-local ranges (e.g. 169.254.169.254).

Documenso&amp;#39;s sign-field-with-token.ts, used by the live document-signing UI, allows a recipient with the ASSISTANT role to fetch and complete fields belonging to any later-or-equal-order, not-yet-signed recipient in the same envelope, with no restriction on field type. A newer V2 signing path (sign-envelope-field.ts) explicitly blocks assistants from completing SIGNATURE fields, and the project&amp;#39;s own test suite comments confirm this guard is absent from the V1 path used here.