News & Sicurezza

CVE ID :CVE-2026-31660 Published : April 24, 2026, 3:16 p.m. | 55 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: allocate rx skb before consuming bytes pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-31661 Published : April 24, 2026, 3:16 p.m. | 55 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: Fix dma_free_coherent() size dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-31662 Published : April 24, 2026, 3:16 p.m. | 55 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round. Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-31656 Published : April 24, 2026, 3:16 p.m. | 55 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` [487.221889] Workqueue: i915-unordered engine_retire [i915] [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... [487.222707] Call Trace: [487.222711] [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] [487.223566] __engine_park+0xb9/0x650 [i915] [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] [487.225238] intel_context_exit+0xf1/0x1b0 [i915] [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] [487.226178] i915_request_retire+0x1c/0x40 [i915] [487.226625] engine_retire+0x122/0x180 [i915] [487.227037] process_one_work+0x239/0x760 [487.227060] worker_thread+0x200/0x3f0 [487.227068] ? __pfx_worker_thread+0x10/0x10 [487.227075] kthread+0x10d/0x150 [487.227083] ? __pfx_kthread+0x10/0x10 [487.227092] ret_from_fork+0x3d4/0x480 [487.227099] ? __pfx_kthread+0x10/0x10 [487.227107] ret_from_fork_asm+0x1a/0x30 [487.227141] ``` Fix this by ...

CVE ID :CVE-2026-31657 Published : April 24, 2026, 3:16 p.m. | 55 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. The netlink claim dump path dereferences claim->backbone_gw->orig and takes claim->backbone_gw->crc_lock without pinning the underlying backbone gateway. batadv_bla_check_claim() still has the same naked pointer access pattern. Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate on a stable gateway reference until the read-side work is complete. This keeps the dump and claim-check paths aligned with the lifetime rules introduced for the other BLA claim readers. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-31658 Published : April 24, 2026, 3:16 p.m. | 55 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-31659 Published : April 24, 2026, 3:16 p.m. | 55 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-31655 Published : April 24, 2026, 3:16 p.m. | 55 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled Keep the NOC_HDCP clock always enabled to fix the potential hang caused by the NoC ADB400 port power down handshake. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-31650 Published : April 24, 2026, 3:16 p.m. | 55 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix use-after-free on disconnect The vub300 driver maintains an explicit reference count for the controller and its driver data and the last reference can in theory be dropped after the driver has been unbound. This specifically means that the controller allocation must not be device managed as that can lead to use-after-free. Note that the lifetime is currently also incorrectly tied the parent USB device rather than interface, which can lead to memory leaks if the driver is unbound without its device being physically disconnected (e.g. on probe deferral). Fix both issues by reverting to non-managed allocation of the controller. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-31651 Published : April 24, 2026, 3:16 p.m. | 55 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix NULL-deref on disconnect Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-31652 Published : April 24, 2026, 3:16 p.m. | 55 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: mm/damon/stat: deallocate damon_call() failure leaking damon_ctx damon_stat_start() always allocates the module's damon_ctx object (damon_stat_context). Meanwhile, if damon_call() in the function fails, the damon_ctx object is not deallocated. Hence, if the damon_call() is failed, and the user writes Y to “enabled” again, the previously allocated damon_ctx object is leaked. This cannot simply be fixed by deallocating the damon_ctx object when damon_call() fails. That's because damon_call() failure doesn't guarantee the kdamond main function, which accesses the damon_ctx object, is completely finished. In other words, if damon_stat_start() deallocates the damon_ctx object after damon_call() failure, the not-yet-terminated kdamond could access the freed memory (use-after-free). Fix the leak while avoiding the use-after-free by keeping returning damon_stat_start() without deallocating the damon_ctx object after damon_call() failure, but deallocating it when the function is invoked again and the kdamond is completely terminated. If the kdamond is not yet terminated, simply return -EAGAIN, as the kdamond will soon be terminated. The issue was discovered [1] by sashiko. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-31653 Published : April 24, 2026, 3:16 p.m. | 55 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: dealloc repeat_call_control if damon_call() fails damon_call() for repeat_call_control of DAMON_SYSFS could fail if somehow the kdamond is stopped before the damon_call(). It could happen, for example, when te damon context was made for monitroing of a virtual address processes, and the process is terminated immediately, before the damon_call() invocation. In the case, the dyanmically allocated repeat_call_control is not deallocated and leaked. Fix the leak by deallocating the repeat_call_control under the damon_call() failure. This issue is discovered by sashiko [1]. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...