🚨 CVE-2023-53408
In the Linux kernel, the following vulnerability has been resolved:

trace/blktrace: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.

🎖@cveNotify

🚨 CVE-2023-53409
In the Linux kernel, the following vulnerability has been resolved:

drivers: base: component: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.

🎖@cveNotify

🚨 CVE-2023-53410
In the Linux kernel, the following vulnerability has been resolved:

USB: ULPI: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.

🎖@cveNotify

🚨 CVE-2023-53411
In the Linux kernel, the following vulnerability has been resolved:

PM: EM: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.

🎖@cveNotify

🚨 CVE-2023-53412
In the Linux kernel, the following vulnerability has been resolved:

USB: gadget: bcm63xx_udc: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.

🎖@cveNotify

🚨 CVE-2023-53413
In the Linux kernel, the following vulnerability has been resolved:

USB: isp116x: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.

🎖@cveNotify

🚨 CVE-2023-53414
In the Linux kernel, the following vulnerability has been resolved:

scsi: snic: Fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic at
once.

🎖@cveNotify

🚨 CVE-2023-53415
In the Linux kernel, the following vulnerability has been resolved:

USB: dwc3: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.

Note, the root dentry for the debugfs directory for the device needs to
be saved so we don't have to keep looking it up, which required a bit
more refactoring to properly create and remove it when needed.

🎖@cveNotify

🚨 CVE-2022-50408
In the Linux kernel, the following vulnerability has been resolved:

wifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit()

> ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb);

may be schedule, and then complete before the line

> ndev->stats.tx_bytes += skb->len;

[ 46.912801] ==================================================================
[ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]
[ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328
[ 46.935991]
[ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1
[ 46.947255] Hardware name: [REDACTED]
[ 46.954568] Call trace:
[ 46.957037] dump_backtrace+0x0/0x2b8
[ 46.960719] show_stack+0x24/0x30
[ 46.964052] dump_stack+0x128/0x194
[ 46.967557] print_address_description.isra.0+0x64/0x380
[ 46.972877] __kasan_report+0x1d4/0x240
[ 46.976723] kasan_report+0xc/0x18
[ 46.980138] __asan_report_load4_noabort+0x18/0x20
[ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]
[ 46.990613] dev_hard_start_xmit+0x1bc/0xda0
[ 46.994894] sch_direct_xmit+0x198/0xd08
[ 46.998827] __qdisc_run+0x37c/0x1dc0
[ 47.002500] __dev_queue_xmit+0x1528/0x21f8
[ 47.006692] dev_queue_xmit+0x24/0x30
[ 47.010366] neigh_resolve_output+0x37c/0x678
[ 47.014734] ip_finish_output2+0x598/0x2458
[ 47.018927] __ip_finish_output+0x300/0x730
[ 47.023118] ip_output+0x2e0/0x430
[ 47.026530] ip_local_out+0x90/0x140
[ 47.030117] igmpv3_sendpack+0x14c/0x228
[ 47.034049] igmpv3_send_cr+0x384/0x6b8
[ 47.037895] igmp_ifc_timer_expire+0x4c/0x118
[ 47.042262] call_timer_fn+0x1cc/0xbe8
[ 47.046021] __run_timers+0x4d8/0xb28
[ 47.049693] run_timer_softirq+0x24/0x40
[ 47.053626] __do_softirq+0x2c0/0x117c
[ 47.057387] irq_exit+0x2dc/0x388
[ 47.060715] __handle_domain_irq+0xb4/0x158
[ 47.064908] gic_handle_irq+0x58/0xb0
[ 47.068581] el0_irq_naked+0x50/0x5c
[ 47.072162]
[ 47.073665] Allocated by task 328:
[ 47.077083] save_stack+0x24/0xb0
[ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0
[ 47.084776] kasan_slab_alloc+0x14/0x20
[ 47.088622] kmem_cache_alloc+0x15c/0x468
[ 47.092643] __alloc_skb+0xa4/0x498
[ 47.096142] igmpv3_newpack+0x158/0xd78
[ 47.099987] add_grhead+0x210/0x288
[ 47.103485] add_grec+0x6b0/0xb70
[ 47.106811] igmpv3_send_cr+0x2e0/0x6b8
[ 47.110657] igmp_ifc_timer_expire+0x4c/0x118
[ 47.115027] call_timer_fn+0x1cc/0xbe8
[ 47.118785] __run_timers+0x4d8/0xb28
[ 47.122457] run_timer_softirq+0x24/0x40
[ 47.126389] __do_softirq+0x2c0/0x117c
[ 47.130142]
[ 47.131643] Freed by task 180:
[ 47.134712] save_stack+0x24/0xb0
[ 47.138041] __kasan_slab_free+0x108/0x180
[ 47.142146] kasan_slab_free+0x10/0x18
[ 47.145904] slab_free_freelist_hook+0xa4/0x1b0
[ 47.150444] kmem_cache_free+0x8c/0x528
[ 47.154292] kfree_skbmem+0x94/0x108
[ 47.157880] consume_skb+0x10c/0x5a8
[ 47.161466] __dev_kfree_skb_any+0x88/0xa0
[ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil]
[ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac]
[ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac]
[ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac]
[ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac]
[ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac]
[ 47.197859] process_one_work+0x7fc/0x1a80
[ 47.201965] worker_thread+0x31c/0xc40
[ 47.205726] kthread+0x2d8/0x370
[ 47.208967] ret_from_fork+0x10/0x18
[ 47.212546]
[ 47.214051] The buggy address belongs to the object at ffffff803f588280
[ 47.214051] which belongs to the cache skbuff_head_cache of size 208
[ 47.227086] The buggy address is located 104 bytes inside of
[ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350)
[ 47.238814] The buggy address belongs to the page:
[ 47.243618] page:ffffffff00dd6200 refcount:1 mapcou
---truncated---

🎖@cveNotify

🚨 CVE-2023-53416
In the Linux kernel, the following vulnerability has been resolved:

USB: isp1362: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.

🎖@cveNotify

🚨 CVE-2023-53417
In the Linux kernel, the following vulnerability has been resolved:

USB: sl811: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.

🎖@cveNotify

🚨 CVE-2023-53418
In the Linux kernel, the following vulnerability has been resolved:

USB: gadget: lpc32xx_udc: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.

🎖@cveNotify

🚨 CVE-2007-1399
Stack-based buffer overflow in the zip:// URL wrapper in PECL ZIP 1.8.3 and earlier, as bundled with PHP 5.2.0 and 5.2.1, allows remote attackers to execute arbitrary code via a long zip:// URL, as demonstrated by actively triggering URL access from a remote PHP interpreter via avatar upload or blog pingback.

🎖@cveNotify

🚨 CVE-2023-5197
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.

Addition and removal of rules from chain bindings within the same transaction causes leads to use-after-free.

We recommend upgrading past commit f15f29fd4779be8a418b66e9d52979bb6d6c2325.

🎖@cveNotify

🚨 CVE-2024-27289
pgx is a PostgreSQL driver and toolkit for Go. Prior to version 4.18.2, SQL injection can occur when all of the following conditions are met: the non-default simple protocol is used; a placeholder for a numeric value must be immediately preceded by a minus; there must be a second placeholder for a string value after the first placeholder; both must be on the same line; and both parameter values must be user-controlled. The problem is resolved in v4.18.2. As a workaround, do not use the simple protocol or do not place a minus directly before a placeholder.

🎖@cveNotify

🚨 CVE-2024-26800
In the Linux kernel, the following vulnerability has been resolved:

tls: fix use-after-free on failed backlog decryption

When the decrypt request goes to the backlog and crypto_aead_decrypt
returns -EBUSY, tls_do_decryption will wait until all async
decryptions have completed. If one of them fails, tls_do_decryption
will return -EBADMSG and tls_decrypt_sg jumps to the error path,
releasing all the pages. But the pages have been passed to the async
callback, and have already been released by tls_decrypt_done.

The only true async case is when crypto_aead_decrypt returns
-EINPROGRESS. With -EBUSY, we already waited so we can tell
tls_sw_recvmsg that the data is available for immediate copy, but we
need to notify tls_decrypt_sg (via the new ->async_done flag) that the
memory has already been released.

🎖@cveNotify

🚨 CVE-2025-49177
A flaw was found in the XFIXES extension. The XFixesSetClientDisconnectMode handler does not validate the request length, allowing a client to read unintended memory from previous requests.

🎖@cveNotify

🚨 CVE-2025-49178
A flaw was found in the X server's request handling. Non-zero 'bytes to ignore' in a client's request can cause the server to skip processing another client's request, potentially leading to a denial of service.

🎖@cveNotify

🚨 CVE-2025-49179
A flaw was found in the X Record extension. The RecordSanityCheckRegisterClients function does not check for an integer overflow when computing request length, which allows a client to bypass length checks.

🎖@cveNotify

🚨 CVE-2024-47866
Ceph is a distributed object, block, and file storage platform. In versions up to and including 19.2.3, using the argument `x-amz-copy-source` to put an object and specifying an empty string as its content leads to the RGW daemon crashing, resulting in a DoS attack. As of time of publication, no known patched versions exist.

🎖@cveNotify

🚨 CVE-2025-13544
A weakness has been identified in ashraf-kabir travel-agency up to 1f25aa03544bc5fb7a9e846f8a7879cecdb0cad3. Affected is an unknown function of the file /customer_register.php. Executing manipulation can lead to unrestricted upload. It is possible to launch the attack remotely. The exploit has been made available to the public and could be exploited. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The vendor was contacted early about this disclosure but did not respond in any way.

🎖@cveNotify