mirror of
https://github.com/trickest/cve.git
synced 2026-11-07 04:29:23 -10:00
Update Tue Sep 8 12:18:58 UTC 2026
This commit is contained in:
trickest-workflows committed
1 parent
fe32f63070
commit
11265fa5d0
135 files changed
+2395
-20
No files matched your search
@@ -0,0 +1,17 @@
|
||||
### [CVE-2006-2839](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2839)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Directory traversal vulnerability in PG Problem Editor module (PGProblemEditor.pm) in WeBWorK Online Homework Delivery System 2.2.0 and earlier allows remote attackers to read and write files outside of the templates directory.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- http://sourceforge.net/mailarchive/forum.php?thread_id=10201693&forum_id=43257
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2009-2306](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2306)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
The ARD-9808 DVR card security camera stores sensitive information under the web root with insufficient access control, which allows remote attackers to download a file containing usernames and passwords via a direct request for dvr.ini.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- http://www.exploit-db.com/exploits/9066
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2019-18193](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18193)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In Unisys Stealth (core) 3.4.108.0, 3.4.209.x, 4.0.027.x and 4.0.114, key material inadvertently logged under certain conditions. Fixed included in 3.4.109, 4.0.027.13, 4.0.125 and 5.0.013.0.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://public.support.unisys.com/common/public/vulnerability/NVD_Detail_Rpt.aspx?ID=52
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2023-41095](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-41095)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Missing Encryption of Security Keys vulnerability in Silicon Labs OpenThread SDK on 32 bit, ARM (SecureVault High modules) allows potential modification or extraction of network credentials stored in flash.This issue affects Silicon Labs OpenThread SDK: 2.3.1 and earlier.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://siliconlabs.lightning.force.com/sfc/servlet.shepherd/document/download/0698Y00000ZkKh7QAF?operationContext=S1
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2023-41096](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-41096)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Missing Encryption of Security Keys vulnerability in Silicon Labs Ember ZNet SDK on 32 bit, ARM (SecureVault High modules) allows potential modification or extraction of network credentials stored in flash.This issue affects Silicon Labs Ember ZNet SDK: 7.3.1 and earlier.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://siliconlabs.lightning.force.com/sfc/servlet.shepherd/document/download/0698Y00000ZkKh7QAF?operationContext=S1
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2023-53292](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-53292)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_noneAfter grabbing q->sysfs_lock, q->elevator may become NULL because ofelevator switch.Fix the NULL dereference on q->elevator by checking it with lock.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -15,7 +15,7 @@ An issue in the handling of URL protocols was addressed with improved logic. Thi
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
No PoCs from references.
|
||||
- http://seclists.org/fulldisclosure/2024/Nov/6
|
||||
|
||||
#### Github
|
||||
- https://github.com/fkie-cad/nvd-json-data-feeds
|
||||
|
||||
@@ -35,7 +35,7 @@
|
||||
|
||||
### Description
|
||||
|
||||
A vulnerability has been identified in SIMATIC Field PG M5 (All versions), SIMATIC IPC BX-21A (All versions < V31.01.07), SIMATIC IPC BX-32A (All versions < V29.01.07), SIMATIC IPC BX-39A (All versions < V29.01.07), SIMATIC IPC BX-59A (All versions < V32.01.04), SIMATIC IPC PX-32A (All versions < V29.01.07), SIMATIC IPC PX-39A (All versions < V29.01.07), SIMATIC IPC PX-39A PRO (All versions < V29.01.07), SIMATIC IPC RC-543A (All versions < V36.01.03), SIMATIC IPC RC-543B (All versions < V35.01.12), SIMATIC IPC RW-543A (All versions < V1.1.4), SIMATIC IPC RW-543B (All versions < V35.02.10), SIMATIC IPC127E (All versions < V27.01.11), SIMATIC IPC227E (All versions), SIMATIC IPC227G (All versions < V28.01.14), SIMATIC IPC277E (All versions), SIMATIC IPC277G (All versions < V28.01.14), SIMATIC IPC277G PRO (All versions < V28.01.14), SIMATIC IPC3000 SMART V3 (All versions), SIMATIC IPC327G (All versions < V28.01.14), SIMATIC IPC347G (All versions), SIMATIC IPC377G (All versions < V28.01.14), SIMATIC IPC427E (All versions), SIMATIC IPC477E (All versions), SIMATIC IPC477E PRO (All versions), SIMATIC IPC527G (All versions), SIMATIC IPC627E (All versions < V25.02.15), SIMATIC IPC647E (All versions < V25.02.15), SIMATIC IPC677E (All versions < V25.02.15), SIMATIC IPC847E (All versions < V25.02.15), SIMATIC ITP1000 (All versions). The affected devices have insufficient protection mechanism for the EFI(Extensible Firmware Interface) variables stored on the device. This could allow an authenticated attacker to alter the secure boot configuration without proper authorization by directly communicate with the flash controller.
|
||||
A vulnerability has been identified in SIMATIC Field PG M5 (All versions), SIMATIC IPC BX-21A (All versions < V31.01.07), SIMATIC IPC BX-32A (All versions < V29.01.07), SIMATIC IPC BX-39A (All versions < V29.01.07), SIMATIC IPC BX-59A (All versions < V32.01.04), SIMATIC IPC PX-32A (All versions < V29.01.07), SIMATIC IPC PX-39A (All versions < V29.01.07), SIMATIC IPC PX-39A PRO (All versions < V29.01.07), SIMATIC IPC RC-543A (All versions < V36.01.03), SIMATIC IPC RC-543B (All versions < V35.01.12), SIMATIC IPC RW-543A (All versions < V1.1.4), SIMATIC IPC RW-543B (All versions < V35.02.10), SIMATIC IPC127E (All versions < V27.01.11), SIMATIC IPC227E (All versions), SIMATIC IPC227G (All versions < V28.01.14), SIMATIC IPC277E (All versions), SIMATIC IPC277G (All versions < V28.01.14), SIMATIC IPC277G PRO (All versions < V28.01.14), SIMATIC IPC3000 SMART V3 (All versions), SIMATIC IPC327G (All versions < V28.01.14), SIMATIC IPC347G (All versions), SIMATIC IPC377G (All versions < V28.01.14), SIMATIC IPC427E (All versions < V21.01.21), SIMATIC IPC477E (All versions < V21.01.21), SIMATIC IPC477E PRO (All versions < V21.01.21), SIMATIC IPC527G (All versions), SIMATIC IPC627E (All versions < V25.02.15), SIMATIC IPC647E (All versions < V25.02.15), SIMATIC IPC677E (All versions < V25.02.15), SIMATIC IPC847E (All versions < V25.02.15), SIMATIC ITP1000 (All versions). The affected devices have insufficient protection mechanism for the EFI(Extensible Firmware Interface) variables stored on the device. This could allow an authenticated attacker to alter the secure boot configuration without proper authorization by directly communicate with the flash controller.
|
||||
|
||||
### POC
|
||||
|
||||
|
||||
@@ -36,7 +36,7 @@
|
||||
|
||||
### Description
|
||||
|
||||
A vulnerability has been identified in SIMATIC Field PG M5 (All versions), SIMATIC Field PG M6 (All versions < V26.01.12), SIMATIC IPC BX-21A (All versions < V31.01.07), SIMATIC IPC BX-32A (All versions < V29.01.07), SIMATIC IPC BX-39A (All versions < V29.01.07), SIMATIC IPC BX-59A (All versions < V32.01.04), SIMATIC IPC PX-32A (All versions < V29.01.07), SIMATIC IPC PX-39A (All versions < V29.01.07), SIMATIC IPC PX-39A PRO (All versions < V29.01.07), SIMATIC IPC RC-543A (All versions < V36.01.03), SIMATIC IPC RC-543B (All versions < V35.01.12), SIMATIC IPC RW-543A (All versions < V1.1.4), SIMATIC IPC RW-543B (All versions < V35.02.10), SIMATIC IPC127E (All versions < V27.01.11), SIMATIC IPC227E (All versions), SIMATIC IPC227G (All versions < V28.01.14), SIMATIC IPC277E (All versions), SIMATIC IPC277G (All versions < V28.01.14), SIMATIC IPC277G PRO (All versions < V28.01.14), SIMATIC IPC3000 SMART V3 (All versions), SIMATIC IPC327G (All versions < V28.01.14), SIMATIC IPC347G (All versions), SIMATIC IPC377G (All versions < V28.01.14), SIMATIC IPC427E (All versions), SIMATIC IPC477E (All versions), SIMATIC IPC477E PRO (All versions), SIMATIC IPC527G (All versions), SIMATIC IPC627E (All versions < V25.02.15), SIMATIC IPC647E (All versions < V25.02.15), SIMATIC IPC677E (All versions < V25.02.15), SIMATIC IPC847E (All versions < V25.02.15), SIMATIC ITP1000 (All versions). The affected devices have insufficient protection mechanism for the EFI(Extensible Firmware Interface) variables stored on the device. This could allow an authenticated attacker to disable the BIOS password without proper authorization by directly communicate with the flash controller.
|
||||
A vulnerability has been identified in SIMATIC Field PG M5 (All versions), SIMATIC Field PG M6 (All versions < V26.01.12), SIMATIC IPC BX-21A (All versions < V31.01.07), SIMATIC IPC BX-32A (All versions < V29.01.07), SIMATIC IPC BX-39A (All versions < V29.01.07), SIMATIC IPC BX-59A (All versions < V32.01.04), SIMATIC IPC PX-32A (All versions < V29.01.07), SIMATIC IPC PX-39A (All versions < V29.01.07), SIMATIC IPC PX-39A PRO (All versions < V29.01.07), SIMATIC IPC RC-543A (All versions < V36.01.03), SIMATIC IPC RC-543B (All versions < V35.01.12), SIMATIC IPC RW-543A (All versions < V1.1.4), SIMATIC IPC RW-543B (All versions < V35.02.10), SIMATIC IPC127E (All versions < V27.01.11), SIMATIC IPC227E (All versions), SIMATIC IPC227G (All versions < V28.01.14), SIMATIC IPC277E (All versions), SIMATIC IPC277G (All versions < V28.01.14), SIMATIC IPC277G PRO (All versions < V28.01.14), SIMATIC IPC3000 SMART V3 (All versions), SIMATIC IPC327G (All versions < V28.01.14), SIMATIC IPC347G (All versions), SIMATIC IPC377G (All versions < V28.01.14), SIMATIC IPC427E (All versions < V21.01.21), SIMATIC IPC477E (All versions < V21.01.21), SIMATIC IPC477E PRO (All versions < V21.01.21), SIMATIC IPC527G (All versions), SIMATIC IPC627E (All versions < V25.02.15), SIMATIC IPC647E (All versions < V25.02.15), SIMATIC IPC677E (All versions < V25.02.15), SIMATIC IPC847E (All versions < V25.02.15), SIMATIC ITP1000 (All versions). The affected devices have insufficient protection mechanism for the EFI(Extensible Firmware Interface) variables stored on the device. This could allow an authenticated attacker to disable the BIOS password without proper authorization by directly communicate with the flash controller.
|
||||
|
||||
### POC
|
||||
|
||||
|
||||
@@ -2,6 +2,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -12,7 +13,7 @@ In the Linux kernel, the following vulnerability has been resolved:io_uring: pre
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
No PoCs from references.
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
- https://github.com/fkie-cad/nvd-json-data-feeds
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
### [CVE-2025-2842](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-2842)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
### [CVE-2025-40196](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-40196)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:fs: quota: create dedicated workqueue for quota_release_workThere is a kernel panic due to WARN_ONCE when panic_on_warn is set.This issue occurs when writeback is triggered due to sync call for anopened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balanceis needed at sync path, flush for quota_release_work is triggered.By default quota_release_work is queued to "events_unbound" queue whichdoes not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback"workqueue tries to flush quota_release_work causing kernel panic due toMEM_RECLAIM flag mismatch errors.This patch creates dedicated workqueue with WQ_MEM_RECLAIM flagfor work quota_release_work.------------[ cut here ]------------WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20Kernel panic - not syncing: kernel: panic_on_warn set ...
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-11628](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-11628)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Use after free in Ozone in Google Chrome prior to 149.0.7827.103 allowed a local attacker to potentially exploit heap corruption via physical access to the device. (Chromium security severity: Critical)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/516501794
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-11644](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-11644)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Use after free in Views in Google Chrome on Linux prior to 149.0.7827.103 allowed an attacker who convinced a user to install a malicious extension to execute arbitrary code via a crafted Chrome Extension. (Chromium security severity: Critical)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/518043597
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-11651](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-11651)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Use after free in Network in Google Chrome prior to 149.0.7827.103 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/511736002
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-11692](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-11692)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Use after free in Read Anything in Google Chrome prior to 149.0.7827.103 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/517607902
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-11695](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-11695)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Inappropriate implementation in Passwords in Google Chrome prior to 149.0.7827.103 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: High)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/517762104
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-11697](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-11697)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Insufficient validation of untrusted input in UI in Google Chrome prior to 149.0.7827.103 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/518105731
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-13490](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-13490)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
A security vulnerability has been detected in glpi-project glpi 11.0.5/11.0.6/11.0.7. This affects the function Document::canViewFile of the file front/document.send.php of the component Document Handler. Such manipulation of the argument docid leads to authorization bypass. The attack can be executed remotely. This attack is characterized by high complexity. It is indicated that the exploitability is difficult. The vendor was contacted early about this disclosure.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://vuldb.com/submit/838225
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-13782](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-13782)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Use after free in Browser in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/516683433
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-13908](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-13908)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Insufficient validation of untrusted input in Omnibox in Google Chrome on iOS prior to 150.0.7871.47 allowed a remote attacker who convinced a user to engage in specific UI gestures to bypass navigation restrictions via malicious network traffic. (Chromium security severity: Medium)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/505242189
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-13921](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-13921)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Insufficient validation of untrusted input in DeviceBoundSessionCredentials in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to bypass same origin policy via a crafted HTML page. (Chromium security severity: Medium)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/511738175
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-14009](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-14009)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Inappropriate implementation in Passwords in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/516819850
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-14011](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-14011)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Out of bounds read in SurfaceCapture in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: Medium)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/516944556
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-14018](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-14018)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Use after free in Updater in Google Chrome on Windows prior to 150.0.7871.47 allowed a local attacker to perform OS-level privilege escalation via a malicious file. (Chromium security severity: Medium)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/517350251
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-14155](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-14155)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Insufficient policy enforcement in StorageAccessAPI in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/518246925
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-14156](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-14156)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Insufficient policy enforcement in StorageAccessAPI in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to bypass same origin policy via a crafted HTML page. (Chromium security severity: Low)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/518247789
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
### [CVE-2026-14413](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-14413)
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
Uninitialized Use in ANGLE in Google Chrome prior to 150.0.7871.46 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://issues.chromium.org/issues/513922055
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
### [CVE-2026-16097](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-16097)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
A vulnerability was found in Shibby Tomato 1.28. This vulnerability affects the function sub_42537C of the component Scheduler Name Handler. The manipulation of the argument a1 results in stack-based buffer overflow. It is possible to launch the attack remotely. This project is superseded by FreshTomato.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://vuldb.com/vuln/379801
|
||||
- https://vuldb.com/vuln/379801/cti
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
### [CVE-2026-18922](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-18922)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
A flaw was found in 389 Directory Server. During SASL PLAIN authentication, a stale identity carried in a Cyrus SASL auxiliary property from a prior failed bind attempt can be installed on a connection following a subsequent, unrelated successful bind, regardless of which SASL mechanism completes that second bind. An attacker can send a SASL PLAIN bind as cn=Directory Manager with an incorrect password, then complete a SASL ANONYMOUS bind on the same connection, causing the server to grant Directory Manager authority without any valid credentials. A variant using a valid low-privileged account's own successful bind instead of an anonymous one is also possible.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://bugzilla.redhat.com/show_bug.cgi?id=2511388
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
### [CVE-2026-19993](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-19993)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
A vulnerability has been found in Webkul Bagisto up to 2.4.4. Affected by this vulnerability is an unknown functionality of the file /customer/account/rma/update-status of the component RMA State Validation. The manipulation leads to enforcement of behavioral workflow. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor confirms: "The reported issues were already identified through our internal security assessment process prior to this notification and are being handled through our established internal security and development lifecycle. Some of these items have already been addressed, while the remaining items are planned for resolution in upcoming product releases."
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://vuldb.com/submit/870354
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-23255](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-23255)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:net: add proper RCU protection to /proc/net/ptypeYin Fengwei reported an RCU stall in ptype_seq_show() and provideda patch.Real issue is that ptype_seq_next() and ptype_seq_show() violateRCU rules.ptype_seq_show() runs under rcu_read_lock(), and reads pt->devto get device name without any barrier.At the same time, concurrent writers can remove a packet_type structure(which is correctly freed after an RCU grace period) and clear pt->devwithout an RCU grace period.Define ptype_iter_state to carry a dev pointer along seq_net_private:struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch};We need to record the device pointer in ptype_get_idx() andptype_seq_next() so that ptype_seq_show() is safe againstconcurrent pt->dev changes.We also need to add full RCU protection in ptype_seq_next().(Missing READ_ONCE() when reading list.next values)Many thanks to Dong Chenchen for providing a repro.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-23399](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-23399)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:nf_tables: nft_dynset: fix possible stateful expression memleak in error pathIf cloning the second stateful expression in the element via GFP_ATOMICfails, then the first stateful expression remains in place without beingreleased. unreferenced object (percpu) 0x607b97e9cab8 (size 16): comm "softirq", pid 0, jiffies 4294931867 hex dump (first 16 bytes on cpu 3): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace (crc 0): pcpu_alloc_noprof+0x453/0xd80 nft_counter_clone+0x9c/0x190 [nf_tables] nft_expr_clone+0x8f/0x1b0 [nf_tables] nft_dynset_new+0x2cb/0x5f0 [nf_tables] nft_rhash_update+0x236/0x11c0 [nf_tables] nft_dynset_eval+0x11f/0x670 [nf_tables] nft_do_chain+0x253/0x1700 [nf_tables] nft_do_chain_ipv4+0x18d/0x270 [nf_tables] nf_hook_slow+0xaa/0x1e0 ip_local_deliver+0x209/0x330
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-31449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-31449)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:ext4: validate p_idx bounds in ext4_ext_correct_indexesext4_ext_correct_indexes() walks up the extent tree correctingindex entries when the first extent in a leaf is modified. Beforeaccessing path[k].p_idx->ei_block, there is no validation thatp_idx falls within the valid range of index entries for thatlevel.If the on-disk extent header contains a corrupted or craftedeh_entries value, p_idx can point past the end of the allocatedbuffer, causing a slab-out-of-bounds read.Fix this by validating path[k].p_idx against EXT_LAST_INDEX() atboth access sites: before the while loop and inside it. Return-EFSCORRUPTED if the index pointer is out of range, consistentwith how other bounds violations are handled in the ext4 extenttree code.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-31681](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-31681)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_multiport: validate range encoding in checkentryports_match_v1() treats any non-zero pflags entry as the start of aport range and unconditionally consumes the next ports[] element asthe range end.The checkentry path currently validates protocol, flags and count, butit does not validate the range encoding itself. As a result, malformedrules can mark the last slot as a range start or place two range startsback to back, leaving ports_match_v1() to step past the last validports[] element while interpreting the rule.Reject malformed multiport v1 rules in checkentry by validating thateach range start has a following element and that the following elementis not itself marked as another range start.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-31700](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-31700)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr pointsdirectly into the mmap'd TX ring buffer shared with userspace. Thekernel validates the header via __packet_snd_vnet_parse() but thenre-reads all fields later in virtio_net_hdr_to_skb(). A concurrentuserspace thread can modify the vnet_hdr fields between validationand use, bypassing all safety checks.The non-TPACKET path (packet_snd()) already correctly copies vnet_hdrto a stack-local variable. All other vnet_hdr consumers in the kernel(tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TXpath is the only caller of virtio_net_hdr_to_skb() that reads directlyfrom user-controlled shared memory.Fix this by copying vnet_hdr from the mmap'd ring buffer to astack-local variable before validation and use, consistent with theapproach used in packet_snd() and all other callers.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
### [CVE-2026-43071](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43071)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:dcache: Limit the minimal number of bucket to twoThere is an OOB read problem on dentry_hashtable when user sets'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260There will be only one bucket in dentry_hashtable when dhash_entries isset as one, and d_hash_shift is calculated as 32 by dcache_init(). Then,following process will access more than one buckets(which memory regionis not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB!Fix it by limiting the minimal number of dentry_hashtable bucket to two,so that 'd_hash_shift' won't exceeds the bit width of type u32.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-43085](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43085)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminatorWhen batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send()appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload vianlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put()helper only zeroes alignment padding after the payload, not the payloaditself, so four bytes of stale kernel heap data are leaked to userspacein the NLMSG_DONE message body.Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializesthe nfgenmsg payload via nfnl_fill_hdr(), consistent with how__build_packet_message() already constructs NFULNL_MSG_PACKET headers.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-43089](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43089)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:xfrm_user: fix info leak in build_mapping()struct xfrm_usersa_id has a one-byte padding hole after the protofield, which ends up never getting set to zero before copying out touserspace. Fix that up by zeroing out the whole structure beforesetting individual variables.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-43116](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43116)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: ensure safe access to master conntrackHolding reference on the expectation is not sufficient, the masterconntrack object can just go away, making exp->master invalid.To access exp->master safely:- Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away.- Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths.This patch goes for extending the nf_conntrack_expect_lock sectionto address this issue for simplicity, in the cases that are describedbelow this is just slightly extending the lock section.The add expectation command already holds a reference to the masterconntrack from ctnetlink_create_expect().However, the delete expectation command needs to grab the spinlockbefore looking up for the expectation. Expand the existing spinlocksection to address this to cover the expectation lookup. Note that,the nf_ct_expect_iterate_net() calls already grabs the spinlock whileiterating over the expectation table, which is correct.The get expectation command needs to grab the spinlock to ensure masterconntrack does not go away. This also expands the existing spinlocksection to cover the expectation lookup too. I needed to move thenetlink skb allocation out of the spinlock to keep it GFP_KERNEL.For the expectation events, the IPEXP_DESTROY event is already deliveredunder the spinlock, just move the delivery of IPEXP_NEW under thespinlock too because the master conntrack event cache is reached throughexp->master.While at it, add lockdep notations to help identify what codepaths needto grab the spinlock.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-43216](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43216)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:net: Drop the lock in skb_may_tx_timestamp()skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock mustnot be taken in IRQ context, only softirq is okay. A few drivers receivethe timestamp via a dedicated interrupt and complete the TX timestampfrom that handler. This will lead to a deadlock if the lock is alreadywrite-locked on the same CPU.Taking the lock can be avoided. The socket (pointed by the skb) willremain valid until the skb is released. The ->sk_socket and ->filemember will be set to NULL once the user closes the socket which mayhappen before the timestamp arrives.If we happen to observe the pointer while the socket is closing butbefore the pointer is set to NULL then we may use it because bothpointer (and the file's cred member) are RCU freed.Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add amatching WRITE_ONCE() where the pointer are cleared.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-43303](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43303)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:mm/page_alloc: clear page->private in free_pages_prepare()Several subsystems (slub, shmem, ttm, etc.) use page->private but don'tclear it before freeing pages. When these pages are later allocated ashigh-order pages and split via split_page(), tail pages retain stalepage->private values.This causes a use-after-free in the swap subsystem. The swap code usespage->private to track swap count continuations, assuming freshlyallocated pages have page->private == 0. When stale values are present,swap_count_continued() incorrectly assumes the continuation list is validand iterates over uninitialized page->lru containing LIST_POISON values,causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860Fix this by clearing page->private in free_pages_prepare(), ensuring allfreed pages have clean state regardless of previous use.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-43492](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43492)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()Yiming reports an integer underflow in mpi_read_raw_from_sgl() whensubtracting "lzeros" from the unsigned "nbytes".For this to happen, the scatterlist "sgl" needs to occupy more bytesthan the "nbytes" parameter and the first "nbytes + 1" bytes of thescatterlist must be zero. Under these conditions, the while loopiterating over the scatterlist will count more zeroes than "nbytes",subtract the number of zeroes from "nbytes" and cause the underflow.When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originallyintroduced the bug, it couldn't be triggered because all callers ofmpi_read_raw_from_sgl() passed a scatterlist whose length was equal to"nbytes".However since commit 63ba4d67594a ("KEYS: asymmetric: Use new cryptointerface without scatterlists"), the underflow can now actually betriggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with alarger "out_len" than "in_len" and filling the "in" buffer with zeroes,crypto_akcipher_sync_prep() will create an all-zero scatterlist used forboth the "src" and "dst" member of struct akcipher_request and therebyfulfil the conditions to trigger the bug: sys_keyctl() keyctl_pkey_e_d_s() asymmetric_key_eds_op() software_key_eds_op() crypto_akcipher_sync_encrypt() crypto_akcipher_sync_prep() crypto_akcipher_encrypt() rsa_enc() mpi_read_raw_from_sgl()To the user this will be visible as a DoS as the kernel spins forever,causing soft lockup splats as a side effect.Fix it.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
@@ -13,6 +14,7 @@ In the Linux kernel, the following vulnerability has been resolved:rtmutex: Use
|
||||
|
||||
#### Reference
|
||||
- http://www.openwall.com/lists/oss-security/2026/07/08/12
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
@@ -13,6 +14,7 @@ In the Linux kernel, the following vulnerability has been resolved:ipv6: rpl: re
|
||||
|
||||
#### Reference
|
||||
- https://bugzilla.redhat.com/show_bug.cgi?id=2480457
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
### [CVE-2026-43997](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43997)
|
||||
|
||||
|
||||
|
||||
&color=brightgreen)
|
||||
|
||||
### Description
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
### [CVE-2026-43999](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43999)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
### [CVE-2026-44007](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-44007)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
### [CVE-2026-45411](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-45411)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-45841](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-45841)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULOnf_osf_match_one() computes ctx->window % f->wss.val in theOSF_WSS_MODULO branch with no guard for f->wss.val == 0. ACAP_NET_ADMIN user can add such a fingerprint via nfnetlink; asubsequent matching TCP SYN divides by zero and panics the kernel.Reject the bogus fingerprint in nfnl_osf_add_callback() above theper-option for-loop. f->wss is per-fingerprint, not per-option, sothe check must run regardless of f->opt_num (including 0). Alsoreject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats thatas "should not happen".Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: <IRQ> nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-46015](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46015)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:tcp: call sk_data_ready() after listener migrationWhen inet_csk_listen_stop() migrates an established child socket froma closing listener to another socket in the same SO_REUSEPORT group,the target listener gets a new accept-queue entry viainet_csk_reqsk_queue_add(), but that path never notifies the targetlistener's waiters. A nonblocking accept() still works because itchecks the queue directly, but poll()/epoll_wait() waiters andblocking accept() callers can also remain asleep indefinitely.Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migrationin inet_csk_listen_stop().However, after inet_csk_reqsk_queue_add() succeeds, the ref acquiredin reuseport_migrate_sock() is effectively transferred tonreq->rsk_listener. Another CPU can then dequeue nreq via accept()or listener shutdown, hit reqsk_put(), and drop that listener ref.Since listeners are SOCK_RCU_FREE, wrap the post-queue_add()dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which alsocovers the existing sock_net(nsk) access in that path.The reqsk_timer_handler() path does not need the same changes for tworeasons: half-open requests become readable only after the final ACK,where tcp_child_process() already wakes the listener; and once nreq isvisible via inet_ehash_insert(), the success path no longer touchesnsk directly.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-46021](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46021)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:thermal: core: Fix thermal zone governor cleanup issuesIf thermal_zone_device_register_with_trips() fails after addinga thermal governor to the thermal zone being registered, thegovernor is not removed from it as appropriate which may lead toa memory leak.In turn, thermal_zone_device_unregister() calls thermal_set_governor()without acquiring the thermal zone lock beforehand which may race witha governor update via sysfs and may lead to a use-after-free in thatcase.Address these issues by adding two thermal_set_governor() calls, one tothermal_release() to remove the governor from the given thermal zone,and one to the thermal zone registration error path to cover failurespreceding the thermal zone device registration.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-46033](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46033)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:crypto: authencesn - reject short ahash digests during instance creationauthencesn requires either a zero authsize or an authsize of at least4 bytes because the ESN encrypt/decrypt paths always move 4 bytes ofhigh-order sequence number data at the end of the authenticated data.While crypto_authenc_esn_setauthsize() already rejects explicitnon-zero authsizes in the range 1..3, crypto_authenc_esn_create()still copied auth->digestsize into inst->alg.maxauthsize withoutvalidating it. The AEAD core then initialized the tfm's defaultauthsize from that value.As a result, selecting an ahash with digest size 1..3, such ascbcmac(cipher_null), exposed authencesn instances whose defaultauthsize was invalid even though setauthsize() would have rejected thesame value. AF_ALG could then trigger the ESN tail handling with atoo-short tag and hit an out-of-bounds access.Reject authencesn instances whose ahash digest size is in the invalidnon-zero range 1..3 so that no tfm can inherit an unsupported defaultauthsize.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-46037](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46037)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:ipv4: icmp: validate reply type before using icmp_pointersExtended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type.That value is outside the range covered by icmp_pointers[], which onlydescribes the traditional ICMP types up to NR_ICMP_TYPES.Avoid consulting icmp_pointers[] for reply types outside that range, anduse array_index_nospec() for the remaining in-range lookup. Normal ICMPreplies keep their existing behavior unchanged.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-46040](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46040)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:inotify: fix watch count leak when fsnotify_add_inode_mark_locked() failsWhen fsnotify_add_inode_mark_locked() fails in inotify_new_watch(),the error path calls inotify_remove_from_idr() but does not calldec_inotify_watches() to undo the preceding inc_inotify_watches().This leaks a watch count, and repeated failures can exhaust themax_user_watches limit with -ENOSPC even when no watches are active.Prior to commit 1cce1eea0aff ("inotify: Convert to using per-namespacelimits"), the watch count was incremented after fsnotify_add_mark_locked()succeeded, so this path was not affected. The conversion movedinc_inotify_watches() before the mark insertion without adding thecorresponding rollback.Add the missing dec_inotify_watches() call in the error path.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,36 @@
|
||||
### [CVE-2026-46046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46046)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all()The commit c8e008b60492 ("ext4: ignore xattrs past end")introduced a refcount leak in when block_csum is false.ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() toget iloc.bh, but never releases it with brelse().
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-46086](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46086)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:net: bridge: use a stable FDB dst snapshot in RCU readersLocal FDB entries can be rewritten in place by `fdb_delete_local()`, whichupdates `f->dst` to another port or to `NULL` while keeping the entryalive. Several bridge RCU readers inspect `f->dst`, including`br_fdb_fillbuf()` through the `brforward_read()` sysfs path.These readers currently load `f->dst` multiple times and can thereforeobserve inconsistent values across the check and later dereference.In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change`f->dst` after the NULL check and before the `port_no` dereference,leading to a NULL-ptr-deref.Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in eachaffected RCU reader and using that snapshot for the rest of the accesssequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()`with `WRITE_ONCE()` so the readers and writer use matching access patterns.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-46101](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46101)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: reject zero shift in nft_bitwiseReject zero shift operands for nft_bitwise left and right shiftexpressions during initialization.The carry propagation logic computes the carry from the adjacent 32-bitword using BITS_PER_TYPE(u32) - shift. A zero shift operand turns thisinto a 32-bit shift, which is undefined behaviour.Reject zero shift operands in the control plane, alongside the existingcheck for values greater than or equal to 32, so malformed rules neverreach the packet path.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-46116](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46116)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:xfrm: defensively unhash xfrm_state lists in __xfrm_state_deleteKASAN reproduces a slab-use-after-free in __xfrm_state_delete()'shlist_del_rcu calls under syzkaller load on linux-6.12.y stable(reproduced on 6.12.47, also reachable via the same code path ontorvalds/master and on the ipsec tree). Nine unique signatures clusterin the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_netThe other observed signatures hit the same slab object from__xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOBwrite variant of __xfrm_state_delete, all on the byseq/byspihash chains.__xfrm_state_delete() guards its byseq and byspi unhashes withvalue-based predicates: if (x->km.seq) hlist_del_rcu(&x->byseq); if (x->id.spi) hlist_del_rcu(&x->byspi);while everywhere else in the file (e.g. state_cache, state_cache_input)the safer hlist_unhashed() check is used. xfrm_alloc_spi() setsx->id.spi = newspi inside xfrm_state_lock and then immediately insertsinto byspi, but a path that observes x->id.spi != 0 outside ofxfrm_state_lock can still skip-or-hit the byspi unhash inconsistentlywith whether x is actually on the list. The same holds for x->km.seqversus byseq, and the bydst/bysrc unhashes have no predicate at all,so a second __xfrm_state_delete() on the same object writes throughLIST_POISON pprev.The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields.Empirical verification: applied this patch on top of v6.12.47, rebuilt,and re-ran the same syzkaller harness for 1h16m on a previously-crashyconfiguration that produced ~100 hits each of slab-use-after-freeRead in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in__xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfoconfirms the xfrm_state slab is actively allocated and freed duringthe run (~143 KiB resident), so the fuzzer is still exercising thosecode paths -- they just no longer crash.Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-46132](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46132)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfortnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stackwithout initialisation: struct ifla_vf_broadcast vf_broadcast;The struct contains a single fixed 32-byte field: /* include/uapi/linux/if_link.h */ struct ifla_vf_broadcast { __u8 broadcast[32]; };The function then copies dev->broadcast into it using dev->addr_lenas the length: memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);On Ethernet devices (the overwhelming majority of SR-IOV NICs)dev->addr_len is 6, so only the first 6 bytes of broadcast[] arewritten. The remaining 26 bytes retain whatever was previously onthe kernel stack. The full struct is then handed to userspace via: nla_put(skb, IFLA_VF_BROADCAST, sizeof(vf_broadcast), &vf_broadcast)leaking up to 26 bytes of uninitialised kernel stack per VF perRTM_GETLINK request, repeatable.The other vf_* structs in the same function are explicitly zeroedfor exactly this reason - see the memset() calls for ivi,vf_vlan_info, node_guid and port_guid a few lines above.vf_broadcast was simply missed when it was added.Reachability: any unprivileged local process can open AF_NETLINK /NETLINK_ROUTE without capabilities and send RTM_GETLINK with anIFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walkseach VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack perVF per request. Stack residue at this call site can include returnaddresses and transient sensitive data; KASAN with stackinstrumentation, or KMSAN, will flag the nla_put() when reproduced.Zero the on-stack struct before the partial memcpy, matching theexisting pattern used for the other vf_* structs in the samefunction.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-46172](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46172)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does notalready have a dst attached. ip6_route_input_lookup() returns areferenced dst entry even when the lookup resolves to an error route.If dst->error is set, xfrm6_rcv_encap() drops the skb without attachingthe dst to the skb and without releasing the reference returned by thelookup. Repeated packets hitting this path therefore leak dst entries.Release the dst before jumping to the drop path.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-46173](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46173)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:exit: prevent preemption of oopsing TASK_DEAD taskWhen an already-exiting task oopses, make_task_dead() currently callsdo_task_dead() with preemption enabled. That is forbidden:do_task_dead() calls __schedule(), which has a comment saying "WARNING:must be called with preemption disabled!".If an oopsing task is preempted in do_task_dead(), between becomingTASK_DEAD and entering the scheduler explicitly, bad things happen:finish_task_switch() assumes that once the scheduler has switched awayfrom a TASK_DEAD task, the task can never run again and its stack is nolonger needed; but that assumption apparently doesn't hold if the deadtask was preempted (the SM_PREEMPT case).This means that the scheduler ends up repeatedly dropping references onthe dead task's stack, which can lead to use-after-free or double-freeof the entire task stack; in other words, two tasks can end up runningon the same stack, resulting in various kinds of memory corruption.(This does not just affect "recursively oopsing" tasks; it is enough tooops once during task exit, for example in a file_operations::releasehandler)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-46193](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46193)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:xfrm: ah: account for ESN high bits in async callbacksAH allocates its temporary auth/ICV layout differently when ESN is enabled:the async ahash setup appends a 4-byte seqhi slot before the ICV orauth_data area, but the async completion callbacks still reconstruct thetemporary layout as if seqhi were absent.With an async AH implementation selected, that makes AH copy or comparethe wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AHwith ESN and forced async hmac(sha1), ping fails with 100% packet loss,and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36Reconstruct the callback-side layout the same way the setup path built itby skipping the ESN seqhi slot before locating the saved auth_data or ICV.Per RFC 4302, the ESN high-order 32 bits participate in the AH ICVcomputation, so the async callbacks must account for the seqhi slot.Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro showsthe corrected offset (ah4 output_done: esn=1 err=0 icv_off=24expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.obuild clean at W=1. IPv6 AH+ESN was not exercised at runtime, and thechange has not been tested against a real async hardware AH engine.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,36 @@
|
||||
### [CVE-2026-46303](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46303)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:isofs: validate Rock Ridge CE continuation extent against volume sizerock_continue() reads rs->cont_extent verbatim from the Rock Ridge CErecord and passes it to sb_bread() without checking that the blocknumber is within the mounted ISO 9660 volume. commit e595447e177b("[PATCH] rock.c: handle corrupted directories") added cont_offsetand cont_size rejection for the CE continuation but did not validatethe extent block number itself. commit f54e18f1b831 ("isofs: Fixinfinite looping over CE entries") later capped the CE chain lengthat RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.With a crafted ISO mounted via udisks2 (desktop optical auto-mount)or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point atan out-of-range block or at blocks belonging to an adjacentfilesystem on the same block device. sb_bread() on an out-of-rangeblock returns NULL cleanly via the block layer EIO path, so thereis no memory-safety violation. For in-range reads of adjacent-filesystem data, the CE buffer is parsed as Rock Ridge records andonly the text of SL sub-records reaches userspace throughreadlink(), which makes the info-leak channel narrow and difficultto exploit; still, rejecting the malformed CE outright matches therejection shape already present in the same function forcont_offset and cont_size.Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() nextto the existing offset/size rejection, printing the samecorrupted-directory-entry notice.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
### [CVE-2026-46306](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46306)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:flow_dissector: do not dissect PPPoE PFC framesRFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOTRECOMMENDED for PPPoE. In practice, pppd does not support negotiatingPFC for PPPoE sessions, and the flow dissector driver has assumed anuncompressed frame until the blamed commit.During the review process of that commit [1], support for PFC issuggested. However, having a compressed (1-byte) protocol field meansthe subsequent PPP payload is shifted by one byte, causing 4-bytemisalignment for the network header and an unaligned access exceptionon some architectures.The exception can be reproduced by sending a PPPoE PFC frame to anethernet interface of a MIPS board, with RPS enabled, even if no PPPoEsession is active on that interface:$ 0 : 00000000 80c40000 00000000 85144817$ 4 : 00000008 00000100 80a75758 81dc9bb8$ 8 : 00000010 8087ae2c 0000003d 00000000$12 : 000000e0 00000039 00000000 00000000$16 : 85043240 80a75758 81dc9bb8 00006488$20 : 0000002f 00000007 85144810 80a70000$24 : 81d1bda0 00000000$28 : 81dc8000 81dc9aa8 00000000 805ead08Hi : 00009d51Lo : 2163358aepc : 805e91f0 __skb_flow_dissect+0x1b0/0x1b50ra : 805ead08 __skb_get_hash_net+0x74/0x12cStatus: 11000403 KERNEL EXL IECause : 40800010 (ExcCode 04)BadVA : 85144817PrId : 0001992f (MIPS 1004Kc)Call Trace:[<805e91f0>] __skb_flow_dissect+0x1b0/0x1b50[<805ead08>] __skb_get_hash_net+0x74/0x12c[<805ef330>] get_rps_cpu+0x1b8/0x3fc[<805fca70>] netif_receive_skb_list_internal+0x324/0x364[<805fd120>] napi_complete_done+0x68/0x2a4[<8058de5c>] mtk_napi_rx+0x228/0xfec[<805fd398>] __napi_poll+0x3c/0x1c4[<805fd754>] napi_threaded_poll_loop+0x234/0x29c[<805fd848>] napi_threaded_poll+0x8c/0xb0[<80053544>] kthread+0x104/0x12c[<80002bd8>] ret_from_kernel_thread+0x14/0x1cCode: 02d51821 1060045b 00000000 <8c640000> 3084000f 2c820005 144001a2 00042080 8e220000To reduce the attack surface and maintain performance, do not processPPPoE PFC frames.[1] https://lore.kernel.org/r/20220630231016.GA392@debian.home
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
@@ -13,6 +14,7 @@ In the Linux kernel, the following vulnerability has been resolved:net: gro: don
|
||||
|
||||
#### Reference
|
||||
- https://bugzilla.redhat.com/show_bug.cgi?id=2479832
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -27,7 +27,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
%20Race%20Condition&color=brightgreen)
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-52910](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-52910)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:bpf: Free reuseport cBPF prog after RCU grace period.Eulgyu Kim reported the splat below with a repro. [0]The repro sets up a UDP reuseport group with a cBPF prog andreplaces it with a new one while another thread is sendinga UDP packet to the group.The reuseport prog is freed by sk_reuseport_prog_free().bpf_prog_put() is called for "e"BPF prog to destruct throughmultiple stages while cBPF prog is freed immediately bybpf_release_orig_filter() and bpf_prog_free().If a reuseport prog is detached from the setsockopt() path(reuseport_attach_prog() or reuseport_detach_prog()),sk_reuseport_prog_free() is called without waiting for RCUreaders to complete, resulting in various bugs.Let's defer freeing the reuseport cBPF prog after one RCUgrace period.Note "e"BPF prog is safe as is unless the fast path startsto touch fields destroyed in bpf_prog_put_deferred() and__bpf_prog_put_noref().[0]:BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596Read of size 4 at addr ffffc9000051e004 by task slowme/10208CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full)Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014Call Trace: <IRQ> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 </IRQ> <TASK> __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x415a2dCode: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2dRDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010R10: 0000000000000000 R11: ---truncated---
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-52912](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-52912)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_queue: hold bridge skb->dev while queuedbr_pass_frame_up() rewrites skb->dev from the ingress port to the bridgemaster before queueing bridge LOCAL_IN packets. NFQUEUE only holdsreferences on state.in/out and bridge physdevs, so a queued bridgepacket can retain a freed bridge master in skb->dev until reinjection.When the verdict is reinjected later, br_netif_receive_skb() re-entersthe 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 queuelifetime, and use the saved device when dropping queued packets duringNETDEV_DOWN handling.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-52930](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-52930)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:ipc/shm: serialize orphan cleanup with shm_nattch updatesshm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but thatdoes not serialize all fields tested by shm_may_destroy(). In particular,shm_nattch is updated while holding shm_perm.lock, and attach paths can dothat without holding the rwsem.Do not decide that an orphaned segment is unused before taking the objectlock. Move the shm_may_destroy() check under shm_perm.lock, matching theother destroy paths, and unlock the segment when it no longer qualifiesfor removal.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
### [CVE-2026-52933](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-52933)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:io_uring/poll: fix signed comparison in io_poll_get_ownership()io_poll_get_ownership() uses a signed comparison to check whetherpoll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS))atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG(BIT(31)) is set in poll_refs, the value becomes negative insigned arithmetic, so the >= 128 comparison always evaluates tofalse and the slowpath is never taken.Fix this by casting the atomic_read() result to unsigned intbefore the comparison, so that the cancel flag is treated as alarge positive value and correctly triggers the slowpath.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-52942](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-52942)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_log: validate MAC header was set before dumping itThe fallback path of dump_mac_header() guards the MAC header accessonly with "skb->mac_header != skb->network_header", without checkingskb_mac_header_was_set(). When the MAC header is unset, mac_header is0xffff, so the test passes and skb_mac_header(skb) returnsskb->head + 0xffff, ~64 KiB past the buffer; the loop then readsdev->hard_header_len bytes out of bounds into the kernel log.This is reachable via the netdev logger: nf_log_unknown_packet() callsdump_mac_header() unconditionally, and an skb sent through AF_PACKETwith PACKET_QDISC_BYPASS reaches the egress hook with mac_header stillunset (__dev_queue_xmit(), which would reset it, is bypassed).Add the skb_mac_header_was_set() check the ARPHRD_ETHER path alreadyuses, and replace the open-coded MAC header length test withskb_mac_header_len(). Only skbs with an unset MAC header are affected;valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
@@ -13,6 +14,7 @@ In the Linux kernel, the following vulnerability has been resolved:net: skbuff:
|
||||
|
||||
#### Reference
|
||||
- https://bugzilla.redhat.com/show_bug.cgi?id=2492137
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-52946](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-52946)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signalingA SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur insend_sigio() and send_sigurg() when a process group receives a signal.When FASYNC is configured for a process group (PIDTYPE_PGID), bothfunctions use read_lock(&tasklist_lock) to traverse the task list.However, they are frequently called from softirq context:- send_sigio() via input_inject_event -> kill_fasync- send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)The deadlock is caused by the rwlock writer fairness mechanism:1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait().2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers.3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.Since PID hashing and do_each_pid_task() traversals are alreadyRCU-protected, the read_lock on tasklist_lock is no longer strictlyrequired for safe traversal. Fix this by replacing tasklist_lock withrcu_read_lock(), aligning the process group signaling path with thesingle-PID path. This also mitigates a potential remote denial ofservice vector via TCP URG packets.Lockdep splat:=====================================================WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected[...]Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lockPossible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); <Interrupt> lock(&dev->event_lock);*** DEADLOCK ***
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-52970](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-52970)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: fix missing expect put in obj evalnft_ct_expect_obj_eval() allocates an expectation and may callnf_ct_expect_related(), but never drops its local reference.Add nf_ct_expect_put(exp) before return to balance allocation.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-52986](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-52986)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_sip: don't use simple_strtoulReplace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(),and ct_sip_parse_request() with a new sip_parse_port() helper thatvalidates each digit against the buffer limit, eliminating the use ofsimple_strtoul() which assumes NUL-terminated strings.The previous code dereferenced pointers without bounds checks aftersip_parse_addr() and relied on simple_strtoul() on non-NUL-terminatedskb data. A port that reaches the buffer limit without a trailingcharacter is also rejected as malformed.Also get rid of all simple_strtoul() usage in conntrack, prefer astricter version instead. There are intentional changes:- Bail out if number is > UINT_MAX and indicate a failure, same for too long sequences. While we do accept 05535 as port 5535, we will not accept e.g. 'sip:10.0.0.1:005060'. While its syntactically valid under RFC 3261, we should restrict this to not waste cycles when presented with malformed packets with 64k '0' characters.- Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch 'expire=' and 'rports='; both are expected to use base-10.- In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k range.- epaddr_len now returns 0 if the port is invalid, as it already does for invalid ip addresses. This is intentional. nf_conntrack_sip performs lots of guesswork to find the right parts of the message to parse. Being stricter could break existing setups. Connection tracking helpers are designed to allow traffic to pass, not to block it.Based on an earlier patch from Jenny Guanni Qu <qguanni@gmail.com>.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-52998](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-52998)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_osf: fix potential NULL dereference in ttl checkThe nf_osf_ttl() function accessed skb->dev to perform a local interfaceaddress lookup without verifying that the device pointer was valid.Additionally, the implementation utilized an in_dev_for_each_ifa_rculoop to match the packet source address against local interfaceaddresses. It assumed that packets from the same subnet should not see adecrement on the initial TTL. A packet might appear it is from the samesubnet but it actually isn't especially in modern environments withcontainers and virtual switching.Remove the device dereference and interface loop. Replace the logic witha switch statement that evaluates the TTL according to the ttl_check.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
### [CVE-2026-52999](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-52999)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_osf: fix out-of-bounds read on option matchingIn nf_osf_match(), the nf_osf_hdr_ctx structure is initialized onceand passed by reference to nf_osf_match_one() for each fingerprintchecked. During TCP option parsing, nf_osf_match_one() advances theshared ctx->optp pointer.If a fingerprint perfectly matches, the function returns early withoutrestoring ctx->optp to its initial state. If the user has configuredNF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint.However, because ctx->optp was not restored, the next call tonf_osf_match_one() starts parsing from the end of the options buffer.This causes subsequent matches to read garbage data and failimmediately, making it impossible to log more than one match or loggingincorrect matches.Instead of using a shared ctx->optp pointer, pass the context as aconstant pointer and use a local pointer (optp) for TCP optiontraversal. This makes nf_osf_match_one() strictly stateless from thecaller's perspective, ensuring every fingerprint check starts at thecorrect option offset.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53001](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53001)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: xtables: restrict several matches to inet familyThis is a partial revert of: commit ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions")to allow ipv4 and ipv6 only.- xt_mac- xt_owner- xt_physdevThese extensions are not used by ebtables in userspace.Moreover, xt_realm is only for ipv4, since dst->tclassid is ipv4specific.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53002](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53002)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: remove sprintf usageReplace it with scnprintf, the buffer sizes are expected to be large enoughto hold the result, no need for snprintf+overflow check.Increase buffer size in mangle_content_len() while at it.BUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270Write of size 1 at addr [..] vsnprintf+0xea5/0x1270 sprintf+0xb1/0xe0 mangle_content_len+0x1ac/0x280 nf_nat_sdp_session+0x1cc/0x240 process_sdp+0x8f8/0xb80 process_invite_request+0x108/0x2b0 process_sip_msg+0x5da/0xf50 sip_help_tcp+0x45e/0x780 nf_confirm+0x34d/0x990 [..]
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53006](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53006)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:ipv6: fix possible UAF in icmpv6_rcv()Caching saddr and daddr before pskb_pull() is problematicsince skb->head can change.Remove these temporary variables:- We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr when net_dbg_ratelimited() is called in the slow path.- Avoid potential future misuse after pskb_pull() call.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53012](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53012)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:nexthop: fix IPv6 route referencing IPv4 nexthopsyzbot reported a panic [1] [2].When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flagof all groups containing this nexthop is not updated. This is becausenh_group_v4_update is only called when replacing AF_INET to AF_INET6,but the reverse direction (AF_INET6 to AF_INET) is missed.This allows a stale has_v4=false to bypass fib6_check_nexthop, causingIPv6 routes to be attached to groups that effectively contain only AF_INETmembers. Subsequent route lookups then call nexthop_fib6_nh() whichreturns NULL for the AF_INET member, leading to a NULL pointerdereference.Fix by calling nh_group_v4_update whenever the family changes, not justAF_INET to AF_INET6.Reproducer: # AF_INET6 blackhole ip -6 nexthop add id 1 blackhole # group with has_v4=false ip nexthop add id 100 group 1 # replace with AF_INET (no -6), has_v4 stays false ip nexthop replace id 1 blackhole # pass stale has_v4 check ip -6 route add 2001:db8::/64 nhid 100 # panic ping -6 2001:db8::1[1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0[2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
### [CVE-2026-53050](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53050)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:quota: Fix race of dquot_scan_active() with quota deactivationdquot_scan_active() can race with quota deactivation inquota_release_workfn() like: CPU0 (quota_release_workfn) CPU1 (dquot_scan_active) ============================== ============================== spin_lock(&dq_list_lock); list_replace_init( &releasing_dquots, &rls_head); /* dquot X on rls_head, dq_count == 0, DQ_ACTIVE_B still set */ spin_unlock(&dq_list_lock); synchronize_srcu(&dquot_srcu); spin_lock(&dq_list_lock); list_for_each_entry(dquot, &inuse_list, dq_inuse) { /* finds dquot X */ dquot_active(X) -> true atomic_inc(&X->dq_count); } spin_unlock(&dq_list_lock); spin_lock(&dq_list_lock); dquot = list_first_entry(&rls_head); WARN_ON_ONCE(atomic_read(&dquot->dq_count));The problem is not only a cosmetic one as under memory pressure thecaller of dquot_scan_active() can end up working on freed dquot.Fix the problem by making sure the dquot is removed from releasing listwhen we acquire a reference to it.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53134](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53134)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_fib: fix stale stack leak via the OIFNAME registerFor NFT_FIB_RESULT_OIFNAME the destination register is declared withlen = IFNAMSIZ (four 32-bit registers), but on the lookup-fail,RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes oneregister via "*dest = 0". The remaining three registers are left aswhatever was on the stack in nft_do_chain()'s struct nft_regs, and adownstream expression that loads the register span can leak thatuninitialised kernel stack to userspace.The NFTA_FIB_F_PRESENT existence check has the same shape: it is onlymeaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result typewhile the eval stores a single byte via nft_reg_store8(), leaving the restof the declared span stale.Fix both: - replace the bare "*dest = 0" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53218](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53218)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_exthdr: fix register tracking for F_PRESENT flagnft_exthdr_init() passes user-controlled priv->len tonft_parse_register_store(), which marks that many bytes in theregister bitmap as initialized. However, when NFT_EXTHDR_F_PRESENTis set, the eval paths write only 1 byte (nft_reg_store8) or4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4,registers beyond the first are never written, retaininguninitialized stack data from nft_regs.Bail out if userspace requests too much data when F_PRESENT is set.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53219](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53219)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: avoid leaking percpu counter pointersThe native and compat get-entries paths copy the fixed rule entry headerfrom the kernelized rule blob to userspace before overwriting the entry'scounter fields with a sanitized counter snapshot.On SMP kernels, entry->counters.pcnt contains the percpu allocationaddress used by x_tables rule counters. A caller can provide a userspacebuffer that faults during the initial fixed-header copy after pcnt hasbeen copied but before the later sanitized counter copy runs. The syscallthen returns -EFAULT while leaving the raw percpu pointer in userspace.Copy only the fixed entry prefix before counters from the kernelized ruleblob, then copy the sanitized counter snapshot into the counter field.Apply this ordering to the IPv4, IPv6, and ARP native and compatget-entries implementations so a fault cannot expose the internal percpucounter pointer.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
### [CVE-2026-53223](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53223)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:net: guard timestamp cmsgs to real error queue skbsskb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skbfrom sk_error_queue. That assumption is not true for AF_PACKET sockets:outgoing packet taps are also delivered to packet sockets withskb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKETinstead of struct sock_exterr_skb.If such an skb is received with timestamping enabled, the generictimestamp cmsg path can read AF_PACKET control-buffer state assock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet dropcounter overlaps opt_stats. An odd drop count makes the path emitSCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linearskbs this copies past the linear head and can trigger hardened usercopy ordisclose adjacent heap contents.Keep skb_is_err_queue() local to net/socket.c, but make it verify thatthe PACKET_OUTGOING marker is paired with the sock_rmem_free destructorinstalled by sock_queue_err_skb(). AF_PACKET receive skbs use normalreceive ownership and no longer pass as error-queue skbs, while legitimatesk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_freeownership.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53236](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53236)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:tcp: restrict SO_ATTACH_FILTER to priv usersThis patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP socketsto users with CAP_NET_ADMIN capability.This blocks potential side-channel attack where an unprivileged applicationattaches a filter to leak TCP sequence/acknowledgment numbers.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53239](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53239)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx()Fix the race by pruning the bin while still holding xfrm_policy_lock,before dropping it. Use __xfrm_policy_inexact_prune_bin() directly sincethe lock is already held. The wrapper xfrm_policy_inexact_prune_bin()becomes unused and is removed.Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53249](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53249)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:ipv4: restrict IPOPT_SSRR and IPOPT_LSRR optionsThis patch restricts setting Loose Source and Record Route (LSRR)and Strict Source and Record Route (SSRR) IP options to userswith CAP_NET_RAW capability.This prevents unprivileged applications from forcing packets to routethrough attacker-controlled nodes to leak TCP ISN and possibly otherprotocol information.While LSRR and SSRR are commonly filtered in many network environments,they may still be supported and forwarded along some network paths.RFC 7126 (Recommendations on Filtering of IPv4 Packets ContainingIPv4 Options) recommend to drop these options in 4.3 and 4.4.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53268](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53268)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack_irc: fix possible out-of-bounds readWhen parsing fails after we've matched the command string weshould bail out instead of trying to match a different command.This helper should be deprecated, given prevalence of TLS I doubt it hasany relevance in 2026.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53269](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53269)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:netfilter: synproxy: add mutex to guard hook reference countingAs the synproxy infrastructure register netfilter hooks on-demand when auser adds the first iptables target or nftables expression, if doneconcurrently they can race each other.Introduce a mutex to serialize the refcount control blocks access fromboth frontends. While a per namespace mutex might be more efficient, itis not needed for target/expression like SYNPROXY.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53275](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53275)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: Fix use-after-free when processing MLD queriesWhen processing an MLD query, a pointer to the multicast group addressis retrieved when initially parsing the packet. This pointer is laterdereferenced without being reloaded despite the fact that the skb headermight have been reallocated following the pskb_may_pull() calls, leadingto a use-after-free [1].Fix by copying the multicast group address when the packet is initiallyparsed.[1]BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512)Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118Workqueue: mld mld_query_workCall Trace:<TASK>dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)print_address_description.constprop.0 (mm/kasan/report.c:378)print_report (mm/kasan/report.c:482)kasan_report (mm/kasan/report.c:595)__mld_query_work (net/ipv6/mcast.c:1512)mld_query_work (net/ipv6/mcast.c:1563)process_one_work (kernel/workqueue.c:3314)worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)kthread (kernel/kthread.c:436)ret_from_fork (arch/x86/kernel/process.c:158)ret_from_fork_asm (arch/x86/entry/entry_64.S:245)</TASK>[...]Freed by task 118:kasan_save_stack (mm/kasan/common.c:57)kasan_save_track (mm/kasan/common.c:78)kasan_save_free_info (mm/kasan/generic.c:584)__kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)pskb_expand_head (net/core/skbuff.c:2335)__pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4))__mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1))mld_query_work (net/ipv6/mcast.c:1563)process_one_work (kernel/workqueue.c:3314)worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)kthread (kernel/kthread.c:436)ret_from_fork (arch/x86/kernel/process.c:158)ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
### [CVE-2026-53295](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53295)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Description
|
||||
|
||||
In the Linux kernel, the following vulnerability has been resolved:mailbox: add sanity check for channel arrayFail gracefully if there is no channel array attached to the mailboxcontroller. Otherwise the later dereference will cause an OOPS whichmight not be seen because mailbox controllers might instantiate veryearly. Remove the comment explaining the obvious while here.
|
||||
|
||||
### POC
|
||||
|
||||
#### Reference
|
||||
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
|
||||
|
||||
#### Github
|
||||
No PoCs found on GitHub currently.
|
||||
|
||||
Loaded 100 of 135 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user