🚨 CVE-2026-9184
The 24liveblog - live blog tool plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the update_lb24_token() AJAX function in versions up to, and including, 2.2. The handler only verifies the 'lb24' nonce (which is generated and localized to any user with block editor access via lb24_block_enqueue_scripts()) and does not verify the user's capabilities or that the supplied user_id belongs to the current user. This makes it possible for authenticated attackers, with author-level access and above, to overwrite the lb24_token, lb24_uid, lb24_refresh_token, and lb24_uname user meta values of any user (including administrators) as well as the corresponding site-wide options, effectively hijacking the plugin's integration with the 24liveblog service.
🎖@cveNotify
The 24liveblog - live blog tool plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the update_lb24_token() AJAX function in versions up to, and including, 2.2. The handler only verifies the 'lb24' nonce (which is generated and localized to any user with block editor access via lb24_block_enqueue_scripts()) and does not verify the user's capabilities or that the supplied user_id belongs to the current user. This makes it possible for authenticated attackers, with author-level access and above, to overwrite the lb24_token, lb24_uid, lb24_refresh_token, and lb24_uname user meta values of any user (including administrators) as well as the corresponding site-wide options, effectively hijacking the plugin's integration with the 24liveblog service.
🎖@cveNotify
🚨 CVE-2026-9612
The WhatsOrder – Instant Checkout for WooCommerce plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.0.1 via the yapacdev_generate_order_pdf. This makes it possible for unauthenticated attackers to extract sensitive customer PII and order details — including full name, email address, phone number, billing address, ordered items with quantities and prices, applied coupons, shipping method, and order total — from any customer's invoice by enumerating sequential order IDs. Invoice HTML files are written to the publicly accessible wp-content/uploads/whatsorder_invoices/ directory, which is created without an .htaccess deny rule or index.php guard, making every invoice directly downloadable over HTTP with no authentication check.
🎖@cveNotify
The WhatsOrder – Instant Checkout for WooCommerce plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.0.1 via the yapacdev_generate_order_pdf. This makes it possible for unauthenticated attackers to extract sensitive customer PII and order details — including full name, email address, phone number, billing address, ordered items with quantities and prices, applied coupons, shipping method, and order total — from any customer's invoice by enumerating sequential order IDs. Invoice HTML files are written to the publicly accessible wp-content/uploads/whatsorder_invoices/ directory, which is created without an .htaccess deny rule or index.php guard, making every invoice directly downloadable over HTTP with no authentication check.
🎖@cveNotify
🚨 CVE-2026-9616
The Generate Security.txt plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.0.12. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to delete the site's security.txt file from the server filesystem or create the .well-known directory by directly invoking the delete_securitytxt or create_wellknown_folder AJAX actions.
🎖@cveNotify
The Generate Security.txt plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.0.12. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to delete the site's security.txt file from the server filesystem or create the .well-known directory by directly invoking the delete_securitytxt or create_wellknown_folder AJAX actions.
🎖@cveNotify
🚨 CVE-2026-9619
The Reviews and Rating – Docplanner plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.1.4. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to trigger outbound scraping of external websites and write scraped review data into the wp_dp_reviews database table, as well as send feature-request emails from the site administrator's email address.
🎖@cveNotify
The Reviews and Rating – Docplanner plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.1.4. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to trigger outbound scraping of external websites and write scraped review data into the wp_dp_reviews database table, as well as send feature-request emails from the site administrator's email address.
🎖@cveNotify
🚨 CVE-2026-9620
The WP Latest Posts plugin for WordPress is vulnerable to Stored Cross-Site Scripting via crafted image src attributes in post content in versions up to, and including, 5.0.11. This is due to insufficient output escaping in the field() and loop() functions, which extract the raw src attribute value from <img> tags within post_content using a regular expression and then reconstruct new <img> elements or CSS background-image declarations by directly concatenating the unescaped value — bypassing WordPress's kses filtering entirely. This makes it possible for authenticated attackers, with author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
🎖@cveNotify
The WP Latest Posts plugin for WordPress is vulnerable to Stored Cross-Site Scripting via crafted image src attributes in post content in versions up to, and including, 5.0.11. This is due to insufficient output escaping in the field() and loop() functions, which extract the raw src attribute value from <img> tags within post_content using a regular expression and then reconstruct new <img> elements or CSS background-image declarations by directly concatenating the unescaped value — bypassing WordPress's kses filtering entirely. This makes it possible for authenticated attackers, with author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
🎖@cveNotify
🚨 CVE-2026-9643
The WP Meta SEO plugin for WordPress is vulnerable to Unauthenticated Stored Cross-Site Scripting via the REQUEST_URI server variable in all versions up to, and including, 4.5.18. When the plugin's `wpmsTemplateRedirect()` hook detects a 404, it concatenates `$_SERVER['HTTP_HOST']` with the raw `$_SERVER['REQUEST_URI']` and inserts that value verbatim into the `wp_wpms_links.link_url` column via `$wpdb->insert()`. This makes it possible for unauthenticated attackers to inject arbitrary web scripts that execute whenever an administrator views the plugin's 404 & Redirects admin page (`/wp-admin/admin.php?page=metaseo_broken_link`).
🎖@cveNotify
The WP Meta SEO plugin for WordPress is vulnerable to Unauthenticated Stored Cross-Site Scripting via the REQUEST_URI server variable in all versions up to, and including, 4.5.18. When the plugin's `wpmsTemplateRedirect()` hook detects a 404, it concatenates `$_SERVER['HTTP_HOST']` with the raw `$_SERVER['REQUEST_URI']` and inserts that value verbatim into the `wp_wpms_links.link_url` column via `$wpdb->insert()`. This makes it possible for unauthenticated attackers to inject arbitrary web scripts that execute whenever an administrator views the plugin's 404 & Redirects admin page (`/wp-admin/admin.php?page=metaseo_broken_link`).
🎖@cveNotify
🚨 CVE-2026-9710
The Cornerstone WordPress plugin before 7.8.8 does not enforce capability checks on one of its CSS-preview request handlers, and exposes the nonce needed to call it to every logged-in user on any wp-admin page, allowing any authenticated user to evaluate dynamic content tokens against arbitrary users and disclose their sensitive metadata including raw password hashes. This affects the premium co Cornerstone page builder distributed bundled with the X , not the unrelated free `cornerstone` Cornerstone WordPress plugin before 7.8.8 (v0.8.x) on the .org repository.
🎖@cveNotify
The Cornerstone WordPress plugin before 7.8.8 does not enforce capability checks on one of its CSS-preview request handlers, and exposes the nonce needed to call it to every logged-in user on any wp-admin page, allowing any authenticated user to evaluate dynamic content tokens against arbitrary users and disclose their sensitive metadata including raw password hashes. This affects the premium co Cornerstone page builder distributed bundled with the X , not the unrelated free `cornerstone` Cornerstone WordPress plugin before 7.8.8 (v0.8.x) on the .org repository.
🎖@cveNotify
WPScan
Themeco Cornerstone < 7.8.8 (Premium, bundled with X Theme) - Subscriber+ Arbitrary User Password Hash Disclosure
See details on Themeco Cornerstone < 7.8.8 (Premium, bundled with X Theme) - Subscriber+ Arbitrary User Password Hash Disclosure CVE 2026-9710. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-9721
The Book a Room Event Calendar plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.9. This is due to missing or incorrect nonce validation on the settings_form()/update_settings() functionality. The plugin's options page handler dispatches on the 'action' POST parameter and calls update_settings(), which persists plugin configuration (including the external database host, username, password, prefix, database name, encryption key, and registration page URL) via update_option(), without ever generating a nonce field in the settings form or verifying one (no wp_nonce_field(), check_admin_referer(), or wp_verify_nonce() exists anywhere in the plugin). This makes it possible for unauthenticated attackers to modify the plugin's database connection settings via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
🎖@cveNotify
The Book a Room Event Calendar plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.9. This is due to missing or incorrect nonce validation on the settings_form()/update_settings() functionality. The plugin's options page handler dispatches on the 'action' POST parameter and calls update_settings(), which persists plugin configuration (including the external database host, username, password, prefix, database name, encryption key, and registration page URL) via update_option(), without ever generating a nonce field in the settings form or verifying one (no wp_nonce_field(), check_admin_referer(), or wp_verify_nonce() exists anywhere in the plugin). This makes it possible for unauthenticated attackers to modify the plugin's database connection settings via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
🎖@cveNotify
🚨 CVE-2026-9724
The MotorDesk plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.1.2. This is due to missing or incorrect nonce validation on the motordesk_admin_home function. This makes it possible for unauthenticated attackers to update the plugin's configuration settings, including the search page URI and custom template directory path via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
🎖@cveNotify
The MotorDesk plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.1.2. This is due to missing or incorrect nonce validation on the motordesk_admin_home function. This makes it possible for unauthenticated attackers to update the plugin's configuration settings, including the search page URI and custom template directory path via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
🎖@cveNotify
🚨 CVE-2026-52912
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_queue: hold bridge skb->dev while queued
br_pass_frame_up() rewrites skb->dev from the ingress port to the bridge
master before queueing bridge LOCAL_IN packets. NFQUEUE only holds
references on state.in/out and bridge physdevs, so a queued bridge
packet can retain a freed bridge master in skb->dev until reinjection.
When the verdict is reinjected later, br_netif_receive_skb() re-enters
the receive path with skb->dev still pointing at the freed bridge master,
triggering a use-after-free.
Store skb->dev in the queue entry, hold a reference on it for the queue
lifetime, and use the saved device when dropping queued packets during
NETDEV_DOWN handling.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_queue: hold bridge skb->dev while queued
br_pass_frame_up() rewrites skb->dev from the ingress port to the bridge
master before queueing bridge LOCAL_IN packets. NFQUEUE only holds
references on state.in/out and bridge physdevs, so a queued bridge
packet can retain a freed bridge master in skb->dev until reinjection.
When the verdict is reinjected later, br_netif_receive_skb() re-enters
the receive path with skb->dev still pointing at the freed bridge master,
triggering a use-after-free.
Store skb->dev in the queue entry, hold a reference on it for the queue
lifetime, and use the saved device when dropping queued packets during
NETDEV_DOWN handling.
🎖@cveNotify
🚨 CVE-2026-52913
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: v: stop OGMv2 on disabled interface
When a batadv_hard_iface is disabled, its mesh_iface pointer is set to
NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via
batadv_v_ogm_queue_on_if() for interfaces that have since lost their
mesh_iface association. This results in a NULL pointer dereference when
batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the
now NULL hard_iface->mesh_iface to retrieve the batadv_priv.
It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that
it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was
called.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: v: stop OGMv2 on disabled interface
When a batadv_hard_iface is disabled, its mesh_iface pointer is set to
NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via
batadv_v_ogm_queue_on_if() for interfaces that have since lost their
mesh_iface association. This results in a NULL pointer dereference when
batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the
now NULL hard_iface->mesh_iface to retrieve the batadv_priv.
It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that
it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was
called.
🎖@cveNotify
🚨 CVE-2026-52914
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: fix fragment reassembly length accounting
batman-adv keeps a running payload length for queued fragments and uses it
to validate a fragment chain before reassembly.
That accounting currently allows the accumulated fragment length to be
truncated during updates. As a result, malformed fragment chains can
bypass the intended validation and drive reassembly with inconsistent
length state, leading to a local denial of service.
Fix the accounting by storing the accumulated length in a length-typed
field and rejecting update overflows before the existing validation logic
runs.
The fix was verified against the original reproducer and against valid
fragment reassembly paths.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: fix fragment reassembly length accounting
batman-adv keeps a running payload length for queued fragments and uses it
to validate a fragment chain before reassembly.
That accounting currently allows the accumulated fragment length to be
truncated during updates. As a result, malformed fragment chains can
bypass the intended validation and drive reassembly with inconsistent
length state, leading to a local denial of service.
Fix the accounting by storing the accumulated length in a length-typed
field and rejecting update overflows before the existing validation logic
runs.
The fix was verified against the original reproducer and against valid
fragment reassembly paths.
🎖@cveNotify
🚨 CVE-2026-52915
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ip6t_hbh: reject oversized option lists
struct ip6t_opts stores at most IP6T_OPTS_OPTSNR option descriptors,
but hbh_mt6_check() does not reject larger optsnr values supplied from
userspace.
Validate optsnr in the rule setup path so only match data that fits the
fixed-size opts array can be installed. This follows the existing xtables
pattern of rejecting invalid user-provided counts in checkentry() and
keeps the packet matching path unchanged.
`struct ip6t_opts` has a fixed `opts[IP6T_OPTS_OPTSNR]` array,
where `IP6T_OPTS_OPTSNR` is 16, then off-by-one array access is possible:
[ 137.924693][ T8692] UBSAN: array-index-out-of-bounds in ../net/ipv6/netfilter/ip6t_hbh.c:110:29
[ 137.926167][ T8692] index 16 is out of range for type '__u16 [16]'
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ip6t_hbh: reject oversized option lists
struct ip6t_opts stores at most IP6T_OPTS_OPTSNR option descriptors,
but hbh_mt6_check() does not reject larger optsnr values supplied from
userspace.
Validate optsnr in the rule setup path so only match data that fits the
fixed-size opts array can be installed. This follows the existing xtables
pattern of rejecting invalid user-provided counts in checkentry() and
keeps the packet matching path unchanged.
`struct ip6t_opts` has a fixed `opts[IP6T_OPTS_OPTSNR]` array,
where `IP6T_OPTS_OPTSNR` is 16, then off-by-one array access is possible:
[ 137.924693][ T8692] UBSAN: array-index-out-of-bounds in ../net/ipv6/netfilter/ip6t_hbh.c:110:29
[ 137.926167][ T8692] index 16 is out of range for type '__u16 [16]'
🎖@cveNotify
🚨 CVE-2026-52916
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: frag: disallow unicast fragment in fragment
batadv_frag_skb_buffer() is called by batadv_batman_skb_recv() when a
BATADV_UNICAST_FRAG packet is received. Once all fragments are collected
and the packet is reassembled, batadv_recv_frag_packet() calls
batadv_batman_skb_recv() again to process the defragmented payload.
A malicious sender can craft a BATADV_UNICAST_FRAG packet whose reassembled
payload is itself a BATADV_UNICAST_FRAG packet (matryoshka-style nesting).
Each nesting level recurses through batadv_batman_skb_recv() without bound,
growing the kernel stack until it is exhausted.
Since refragmentation or fragments in fragments are not actually allowed,
discard all packets which are still BATADV_UNICAST_FRAG packets after the
defragmentation process.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: frag: disallow unicast fragment in fragment
batadv_frag_skb_buffer() is called by batadv_batman_skb_recv() when a
BATADV_UNICAST_FRAG packet is received. Once all fragments are collected
and the packet is reassembled, batadv_recv_frag_packet() calls
batadv_batman_skb_recv() again to process the defragmented payload.
A malicious sender can craft a BATADV_UNICAST_FRAG packet whose reassembled
payload is itself a BATADV_UNICAST_FRAG packet (matryoshka-style nesting).
Each nesting level recurses through batadv_batman_skb_recv() without bound,
growing the kernel stack until it is exhausted.
Since refragmentation or fragments in fragments are not actually allowed,
discard all packets which are still BATADV_UNICAST_FRAG packets after the
defragmentation process.
🎖@cveNotify
🚨 CVE-2026-52917
In the Linux kernel, the following vulnerability has been resolved:
sctp: diag: reject stale associations in dump_one path
The SCTP exact sock_diag lookup can hold a transport reference, block on
lock_sock(sk), and then resume after sctp_association_free() has marked
the association dead and freed its bind address list.
When that happens, inet_assoc_attr_size() and
inet_diag_msg_sctpasoc_fill() can still dereference association state
that is no longer valid for reporting. In particular,
inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a
real sctp_sockaddr_entry and trigger an out-of-bounds read from
unrelated association memory.
Reject the association after taking the socket lock if it has been
reaped or detached from the endpoint, and report the lookup as stale.
This keeps the exact dump-one path from formatting torn association
state.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
sctp: diag: reject stale associations in dump_one path
The SCTP exact sock_diag lookup can hold a transport reference, block on
lock_sock(sk), and then resume after sctp_association_free() has marked
the association dead and freed its bind address list.
When that happens, inet_assoc_attr_size() and
inet_diag_msg_sctpasoc_fill() can still dereference association state
that is no longer valid for reporting. In particular,
inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a
real sctp_sockaddr_entry and trigger an out-of-bounds read from
unrelated association memory.
Reject the association after taking the socket lock if it has been
reaped or detached from the endpoint, and report the lookup as stale.
This keeps the exact dump-one path from formatting torn association
state.
🎖@cveNotify
🚨 CVE-2026-52918
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: serialize accept_q access
bt_sock_poll() walks the accept queue without synchronization, while
child teardown can unlink the same socket and drop its last reference.
The unsynchronized accept queue walk has existed since the initial
Bluetooth import.
Protect accept_q with a dedicated lock for queue updates and polling.
Also rework bt_accept_dequeue() to take temporary child references under
the queue lock before dropping it and locking the child socket.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: serialize accept_q access
bt_sock_poll() walks the accept queue without synchronization, while
child teardown can unlink the same socket and drop its last reference.
The unsynchronized accept queue walk has existed since the initial
Bluetooth import.
Protect accept_q with a dedicated lock for queue updates and polling.
Also rework bt_accept_dequeue() to take temporary child references under
the queue lock before dropping it and locking the child socket.
🎖@cveNotify
🚨 CVE-2026-52919
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: fix tp_meter counter underflow during shutdown
batadv_tp_sender_shutdown() unconditionally decrements the "sending"
atomic counter. If multiple paths (e.g. timeout, user cancel, and
normal finish) call this function, the counter can underflow to -1.
Since the sender logic treats any non-zero value as "still sending",
a negative value causes the sender kthread to loop indefinitely.
This leads to a use-after-free when the interface is removed while
the zombie thread is still active.
Fix this by using atomic_xchg() to ensure the counter only transitions
from 1 to 0 once.
[sven: added missing change in batadv_tp_send]
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: fix tp_meter counter underflow during shutdown
batadv_tp_sender_shutdown() unconditionally decrements the "sending"
atomic counter. If multiple paths (e.g. timeout, user cancel, and
normal finish) call this function, the counter can underflow to -1.
Since the sender logic treats any non-zero value as "still sending",
a negative value causes the sender kthread to loop indefinitely.
This leads to a use-after-free when the interface is removed while
the zombie thread is still active.
Fix this by using atomic_xchg() to ensure the counter only transitions
from 1 to 0 once.
[sven: added missing change in batadv_tp_send]
🎖@cveNotify
🚨 CVE-2026-52920
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_policy: fix strict mode inbound policy matching
match_policy_in() walks sec_path entries from the last transform to the
first one, but strict policy matching needs to consume info->pol[] in
the same forward order as the rule layout.
Derive the strict-match policy position from the number of transforms
already consumed so that multi-element inbound rules are matched
consistently.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_policy: fix strict mode inbound policy matching
match_policy_in() walks sec_path entries from the last transform to the
first one, but strict policy matching needs to consume info->pol[] in
the same forward order as the rule layout.
Derive the strict-match policy position from the number of transforms
already consumed so that multi-element inbound rules are matched
consistently.
🎖@cveNotify
🚨 CVE-2026-52921
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: stop hash:* range iteration at end
The following hash set variants:
hash:ip,mark
hash:ip,port
hash:ip,port,ip
hash:ip,port,net
iterate IPv4 ranges with a 32-bit iterator.
The iterator must stop once the last address in the requested range has
been processed. Advancing it once more can move the traversal state past
the end of the request, so a later retry may continue from an unintended
position.
Handle the iterator increment explicitly at the end of the loop and stop
once the upper bound has been processed. This keeps the existing retry
behaviour intact for valid ranges while preventing traversal from
continuing past the original boundary.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: stop hash:* range iteration at end
The following hash set variants:
hash:ip,mark
hash:ip,port
hash:ip,port,ip
hash:ip,port,net
iterate IPv4 ranges with a 32-bit iterator.
The iterator must stop once the last address in the requested range has
been processed. Advancing it once more can move the traversal state past
the end of the request, so a later retry may continue from an unintended
position.
Handle the iterator increment explicitly at the end of the loop and stop
once the upper bound has been processed. This keeps the existing retry
behaviour intact for valid ranges while preventing traversal from
continuing past the original boundary.
🎖@cveNotify
🚨 CVE-2026-52922
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: dat: handle forward allocation error
batadv_dat_forward_data() calls pskb_copy_for_clone() to duplicate an skb
for each DHT candidate, but does not check the return value before passing
it to batadv_send_skb_prepare_unicast_4addr(). That function dereferences
the skb unconditionally, so a failed allocation triggers a NULL pointer
dereference.
Skip forwarding to the current DHT candidate on allocation failure.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: dat: handle forward allocation error
batadv_dat_forward_data() calls pskb_copy_for_clone() to duplicate an skb
for each DHT candidate, but does not check the return value before passing
it to batadv_send_skb_prepare_unicast_4addr(). That function dereferences
the skb unconditionally, so a failed allocation triggers a NULL pointer
dereference.
Skip forwarding to the current DHT candidate on allocation failure.
🎖@cveNotify
🚨 CVE-2026-52923
In the Linux kernel, the following vulnerability has been resolved:
ipc: limit next_id allocation to the valid ID range
The checkpoint/restore sysctl path can request the next SysV IPC id
through ids->next_id. ipc_idr_alloc() currently forwards that request to
idr_alloc() with an open-ended upper bound.
If the valid tail of the SysV IPC id space is full, the allocation can
spill beyond ipc_mni. The returned SysV IPC id still uses the normal
index encoding, so later lookup and removal can target the wrong slot.
This leaves the real IDR entry behind and breaks the IDR state for the
object.
The bug is in ipc_idr_alloc() in the checkpoint/restore path.
1. ids->next_id is passed to:
idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...)
2. The zero upper bound makes the allocation effectively open-ended.
Once the valid SysV IPC tail is occupied, idr_alloc() can spill past
ipc_mni and allocate an entry beyond the valid IPC id range.
3. The new object id is still encoded with the narrower SysV IPC index
width:
new->id = (new->seq << ipcmni_seq_shift()) + idx
4. Later removal goes through ipc_rmid(), which uses:
ipcid_to_idx(ipcp->id)
That truncates the real IDR index. An object actually stored at a
high index can then be removed as if it lived at a low in-range
index.
5. For shared memory, shm_destroy() frees the current object anyway, but
the real high IDR slot is left behind as a dangling pointer.
6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry
and dereferences freed memory.
Prevent this by bounding the requested allocation to ipc_mni so the
checkpoint/restore path fails once the valid range is exhausted.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
ipc: limit next_id allocation to the valid ID range
The checkpoint/restore sysctl path can request the next SysV IPC id
through ids->next_id. ipc_idr_alloc() currently forwards that request to
idr_alloc() with an open-ended upper bound.
If the valid tail of the SysV IPC id space is full, the allocation can
spill beyond ipc_mni. The returned SysV IPC id still uses the normal
index encoding, so later lookup and removal can target the wrong slot.
This leaves the real IDR entry behind and breaks the IDR state for the
object.
The bug is in ipc_idr_alloc() in the checkpoint/restore path.
1. ids->next_id is passed to:
idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...)
2. The zero upper bound makes the allocation effectively open-ended.
Once the valid SysV IPC tail is occupied, idr_alloc() can spill past
ipc_mni and allocate an entry beyond the valid IPC id range.
3. The new object id is still encoded with the narrower SysV IPC index
width:
new->id = (new->seq << ipcmni_seq_shift()) + idx
4. Later removal goes through ipc_rmid(), which uses:
ipcid_to_idx(ipcp->id)
That truncates the real IDR index. An object actually stored at a
high index can then be removed as if it lived at a low in-range
index.
5. For shared memory, shm_destroy() frees the current object anyway, but
the real high IDR slot is left behind as a dangling pointer.
6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry
and dereferences freed memory.
Prevent this by bounding the requested allocation to ipc_mni so the
checkpoint/restore path fails once the valid range is exhausted.
🎖@cveNotify