π¨ CVE-2025-36157
IBM Jazz Foundation 7.0.2 to 7.0.2 iFix035, 7.0.3 to 7.0.3 iFix018, and 7.1.0 to 7.1.0 iFix004 could allow an unauthenticated remote attacker to update server property files that would allow them to perform unauthorized actions.
π@cveNotify
IBM Jazz Foundation 7.0.2 to 7.0.2 iFix035, 7.0.3 to 7.0.3 iFix018, and 7.1.0 to 7.1.0 iFix004 could allow an unauthenticated remote attacker to update server property files that would allow them to perform unauthorized actions.
π@cveNotify
Ibm
Security Bulletin: IBM Engineering Lifecycle Management - Jazz Foundation is impacted by a remote attack to the root directoryβ¦
IBM Engineering Lifecycle Management could allow an unauthenticated remote attacker to update server configuration files which would allow them to perform unauthorized actions, subsequently leading to a Denial of Service condition. The associated CVE isβ¦
π¨ CVE-2025-10588
The PixelYourSite β Your smart PIXEL (TAG) & API Manager plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 11.1.2. This is due to missing or incorrect nonce validation on the adminEnableGdprAjax() function. This makes it possible for unauthenticated attackers to modify GDPR settings via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
π@cveNotify
The PixelYourSite β Your smart PIXEL (TAG) & API Manager plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 11.1.2. This is due to missing or incorrect nonce validation on the adminEnableGdprAjax() function. This makes it possible for unauthenticated attackers to modify GDPR settings via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
π@cveNotify
π¨ CVE-2025-67896
Exim before 4.99.1, with certain non-default rate-limit configurations, allows a remote heap-based buffer overflow because database records are cast directly to internal structures without validation.
π@cveNotify
Exim before 4.99.1, with certain non-default rate-limit configurations, allows a remote heap-based buffer overflow because database records are cast directly to internal structures without validation.
π@cveNotify
π¨ CVE-2025-67906
In MISP before 2.5.28, app/View/Elements/Workflows/executionPath.ctp allows XSS in the workflow execution path.
π@cveNotify
In MISP before 2.5.28, app/View/Elements/Workflows/executionPath.ctp allows XSS in the workflow execution path.
π@cveNotify
GitHub
fix: [security] XSS in workflow execution-path Β· MISP/MISP@1f39deb
- As reported by Franck FERMAN
π¨ CVE-2025-36360
IBM UCD - IBM UrbanCode Deploy 7.1 through 7.1.2.27, 7.2 through 7.2.3.20, and 7.3 through 7.3.2.15 and IBM UCD - IBM DevOps Deploy 8.0 through 8.0.1.10, and 8.1 through 8.1.2.3 is susceptible to a race condition in http-session client-IP binding enforcement which may allow a session to be briefly reused from a new IP address before it is invalidated, potentially enabling unauthorized access under certain network conditions.
π@cveNotify
IBM UCD - IBM UrbanCode Deploy 7.1 through 7.1.2.27, 7.2 through 7.2.3.20, and 7.3 through 7.3.2.15 and IBM UCD - IBM DevOps Deploy 8.0 through 8.0.1.10, and 8.1 through 8.1.2.3 is susceptible to a race condition in http-session client-IP binding enforcement which may allow a session to be briefly reused from a new IP address before it is invalidated, potentially enabling unauthorized access under certain network conditions.
π@cveNotify
Ibm
Security Bulletin: IBM DevOps Deploy / IBM UrbanCode Deploy (UCD) is susceptible to an Insufficient Session Expiration vulnerabilityβ¦
IBM DevOps Deploy / IBM UrbanCode Deploy (UCD) is susceptible to a race condition in http-session client-IP binding enforcement which may allow a session to be briefly reused from a new IP address before it is invalidated. This could lead to unauthorizedβ¦
π¨ CVE-2024-36647
A stored cross-site scripting (XSS) vulnerability in Church CRM v5.8.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Family Name parameter under the Register a New Family page.
π@cveNotify
A stored cross-site scripting (XSS) vulnerability in Church CRM v5.8.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Family Name parameter under the Register a New Family page.
π@cveNotify
GitHub
Stored XSS from external family registration Β· Issue #7029 Β· ChurchCRM/CRM
Description A stored XSS vulnerability has been found in Church CRM when the application default setting is open to register the family without the login. ChurchCRM version: 5.8.0 ChurchCRM is runn...
π¨ CVE-2025-67875
ChurchCRM is an open-source church management system. A privilege escalation vulnerability exists in ChurchCRM prior to version 6.5.3. An authenticated user with specific mid-level permissions ("Edit Records" and "Manage Properties and Classifications") can inject a persistent Cross-Site Scripting (XSS) payload into an administrator's profile. The payload executes when the administrator views their own profile page, allowing the attacker to hijack the administrator's session, perform administrative actions, and achieve a full account takeover. This vulnerability is a combination of two separate flaws: an Insecure Direct Object Reference (IDOR) that allows any user to view any other user's profile, and a Broken Access Control vulnerability that allows a user with general edit permissions to modify any other user's record properties. Version 6.5.3 fixes the issue.
π@cveNotify
ChurchCRM is an open-source church management system. A privilege escalation vulnerability exists in ChurchCRM prior to version 6.5.3. An authenticated user with specific mid-level permissions ("Edit Records" and "Manage Properties and Classifications") can inject a persistent Cross-Site Scripting (XSS) payload into an administrator's profile. The payload executes when the administrator views their own profile page, allowing the attacker to hijack the administrator's session, perform administrative actions, and achieve a full account takeover. This vulnerability is a combination of two separate flaws: an Insecure Direct Object Reference (IDOR) that allows any user to view any other user's profile, and a Broken Access Control vulnerability that allows a user with general edit permissions to modify any other user's record properties. Version 6.5.3 fixes the issue.
π@cveNotify
GitHub
Stored XSS via Person Property Assignment Leading to Admin Session Hijacking
### Summary
A critical privilege escalation vulnerability exists in ChurchCRM version 6.3.0 and earlier. An authenticated user with specific mid-level permissions ("Edit Records" and &qu...
A critical privilege escalation vulnerability exists in ChurchCRM version 6.3.0 and earlier. An authenticated user with specific mid-level permissions ("Edit Records" and &qu...
π¨ CVE-2025-67876
ChurchCRM is an open-source church management system. A stored cross-site scripting (XSS) vulnerability exists in ChurchCRM versions 6.4.0 and prior that allows a low-privilege user with the βManage Groupsβ permission to inject persistent JavaScript into group role names. The payload is saved in the database and executed whenever any user (including administrators) views a page that displays that role, such as GroupView.php or PersonView.php. This allows full session hijacking and account takeover. As of time of publication, no known patched versions are available.
π@cveNotify
ChurchCRM is an open-source church management system. A stored cross-site scripting (XSS) vulnerability exists in ChurchCRM versions 6.4.0 and prior that allows a low-privilege user with the βManage Groupsβ permission to inject persistent JavaScript into group role names. The payload is saved in the database and executed whenever any user (including administrators) views a page that displays that role, such as GroupView.php or PersonView.php. This allows full session hijacking and account takeover. As of time of publication, no known patched versions are available.
π@cveNotify
GitHub
Stored XSS in Group Role Name Leading to Admin Session Hijacking
### Summary
A stored cross-site scripting (XSS) vulnerability exists in ChurchCRM that allows a low-privilege user with the βManage Groupsβ permission to inject persistent JavaScript into group ro...
A stored cross-site scripting (XSS) vulnerability exists in ChurchCRM that allows a low-privilege user with the βManage Groupsβ permission to inject persistent JavaScript into group ro...
π¨ CVE-2025-67877
ChurchCRM is an open-source church management system. Versions prior to 6.5.3 have a SQL injection vulnerability in the `src/CartToFamily.php` file, specifically in how the `PersonAddress` POST parameter is handled. Unlike other parameters in the same file which are correctly cast to integers using the `InputUtils` class, the `PersonAddress` parameter is missing the type definition. This allows an attacker to inject arbitrary SQL commands directly into the query. Version 6.5.3 fixes the issue.
π@cveNotify
ChurchCRM is an open-source church management system. Versions prior to 6.5.3 have a SQL injection vulnerability in the `src/CartToFamily.php` file, specifically in how the `PersonAddress` POST parameter is handled. Unlike other parameters in the same file which are correctly cast to integers using the `InputUtils` class, the `PersonAddress` parameter is missing the type definition. This allows an attacker to inject arbitrary SQL commands directly into the query. Version 6.5.3 fixes the issue.
π@cveNotify
GitHub
SQL Injection Vulnerability
# Security Advisory: SQL Injection Vulnerability in `CartToFamily.php`
**Date:** December 06, 2025
**Reporter:** Guilherme Mury
**Severity:** High / Critical
**Affected Component:** `/src/Car...
**Date:** December 06, 2025
**Reporter:** Guilherme Mury
**Severity:** High / Critical
**Affected Component:** `/src/Car...
π¨ CVE-2025-68109
ChurchCRM is an open-source church management system. In versions prior to 6.5.3, the Database Restore functionality does not validate the content or file extension of uploaded files. As a result, an attacker can upload a web shell file and subsequently upload a .htaccess file to enable direct access to it. Once accessed, the uploaded web shell allows remote code execution (RCE) on the server. Version 6.5.3 fixes the issue.
π@cveNotify
ChurchCRM is an open-source church management system. In versions prior to 6.5.3, the Database Restore functionality does not validate the content or file extension of uploaded files. As a result, an attacker can upload a web shell file and subsequently upload a .htaccess file to enable direct access to it. Once accessed, the uploaded web shell allows remote code execution (RCE) on the server. Version 6.5.3 fixes the issue.
π@cveNotify
GitHub
RCE with database restore funcionality
### Summary
It was identified that the Database Restore functionality does not validate the content or file extension of uploaded files. As a result, an attacker can upload a web shell file and su...
It was identified that the Database Restore functionality does not validate the content or file extension of uploaded files. As a result, an attacker can upload a web shell file and su...
π¨ CVE-2025-68110
ChurchCRM is an open-source church management system. Versions prior to 6.5.3 may disclose database information in an error message including the host, ip, username, and password. Version 6.5.3 fixes the issue.
π@cveNotify
ChurchCRM is an open-source church management system. Versions prior to 6.5.3 may disclose database information in an error message including the host, ip, username, and password. Version 6.5.3 fixes the issue.
π@cveNotify
GitHub
Databse information disclosed on error messsage
### Summary
Database information disclosurwe in error message including host , ip username and password included.
### Details
When databse has an error uncaught exception database information ...
Database information disclosurwe in error message including host , ip username and password included.
### Details
When databse has an error uncaught exception database information ...
π¨ CVE-2025-26794
Exim 4.98 before 4.98.1, when SQLite hints and ETRN serialization are used, allows remote SQL injection. (Resolving SQL injection requires an update to 4.99.1 in certain non-default rate-limit configurations.)
π@cveNotify
Exim 4.98 before 4.98.1, when SQLite hints and ETRN serialization are used, allows remote SQL injection. (Resolving SQL injection requires an update to 4.99.1 in certain non-default rate-limit configurations.)
π@cveNotify
π₯1
π¨ CVE-2025-38215
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var
If fb_add_videomode() in do_register_framebuffer() fails to allocate
memory for fb_videomode, it will later lead to a null-ptr dereference in
fb_videomode_to_var(), as the fb_info is registered while not having the
mode in modelist that is expected to be there, i.e. the one that is
described in fb_info->var.
================================================================
general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901
Call Trace:
display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929
fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071
resize_screen drivers/tty/vt/vt.c:1176 [inline]
vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263
fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720
fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776
do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128
fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl fs/ioctl.c:739 [inline]
__x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739
do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x67/0xd1
================================================================
Even though fbcon_init() checks beforehand if fb_match_mode() in
var_to_display() fails, it can not prevent the panic because fbcon_init()
does not return error code. Considering this and the comment in the code
about fb_match_mode() returning NULL - "This should not happen" - it is
better to prevent registering the fb_info if its mode was not set
successfully. Also move fb_add_videomode() closer to the beginning of
do_register_framebuffer() to avoid having to do the cleanup on fail.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var
If fb_add_videomode() in do_register_framebuffer() fails to allocate
memory for fb_videomode, it will later lead to a null-ptr dereference in
fb_videomode_to_var(), as the fb_info is registered while not having the
mode in modelist that is expected to be there, i.e. the one that is
described in fb_info->var.
================================================================
general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901
Call Trace:
display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929
fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071
resize_screen drivers/tty/vt/vt.c:1176 [inline]
vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263
fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720
fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776
do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128
fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl fs/ioctl.c:739 [inline]
__x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739
do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x67/0xd1
================================================================
Even though fbcon_init() checks beforehand if fb_match_mode() in
var_to_display() fails, it can not prevent the panic because fbcon_init()
does not return error code. Considering this and the comment in the code
about fb_match_mode() returning NULL - "This should not happen" - it is
better to prevent registering the fb_info if its mode was not set
successfully. Also move fb_add_videomode() closer to the beginning of
do_register_framebuffer() to avoid having to do the cleanup on fail.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
π@cveNotify
π¨ CVE-2025-38218
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on sit_bitmap_size
w/ below testcase, resize will generate a corrupted image which
contains inconsistent metadata, so when mounting such image, it
will trigger kernel panic:
touch img
truncate -s $((512*1024*1024*1024)) img
mkfs.f2fs -f img $((256*1024*1024))
resize.f2fs -s -i img -t $((1024*1024*1024))
mount img /mnt/f2fs
------------[ cut here ]------------
kernel BUG at fs/f2fs/segment.h:863!
Oops: invalid opcode: 0000 [#1] SMP PTI
CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490
Call Trace:
f2fs_build_segment_manager+0x11c3/0x2600
f2fs_fill_super+0xe97/0x2840
mount_bdev+0xf4/0x140
legacy_get_tree+0x2b/0x50
vfs_get_tree+0x29/0xd0
path_mount+0x487/0xaf0
__x64_sys_mount+0x116/0x150
do_syscall_64+0x82/0x190
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fdbfde1bcfe
The reaseon is:
sit_i->bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum
there are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt
is 4762, build_sit_entries() -> current_sit_addr() tries to access
out-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap
and sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on().
Let's add sanity check in f2fs_sanity_check_ckpt() to avoid panic.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on sit_bitmap_size
w/ below testcase, resize will generate a corrupted image which
contains inconsistent metadata, so when mounting such image, it
will trigger kernel panic:
touch img
truncate -s $((512*1024*1024*1024)) img
mkfs.f2fs -f img $((256*1024*1024))
resize.f2fs -s -i img -t $((1024*1024*1024))
mount img /mnt/f2fs
------------[ cut here ]------------
kernel BUG at fs/f2fs/segment.h:863!
Oops: invalid opcode: 0000 [#1] SMP PTI
CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490
Call Trace:
f2fs_build_segment_manager+0x11c3/0x2600
f2fs_fill_super+0xe97/0x2840
mount_bdev+0xf4/0x140
legacy_get_tree+0x2b/0x50
vfs_get_tree+0x29/0xd0
path_mount+0x487/0xaf0
__x64_sys_mount+0x116/0x150
do_syscall_64+0x82/0x190
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fdbfde1bcfe
The reaseon is:
sit_i->bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum
there are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt
is 4762, build_sit_entries() -> current_sit_addr() tries to access
out-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap
and sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on().
Let's add sanity check in f2fs_sanity_check_ckpt() to avoid panic.
π@cveNotify
π¨ CVE-2025-38158
In the Linux kernel, the following vulnerability has been resolved:
hisi_acc_vfio_pci: fix XQE dma address error
The dma addresses of EQE and AEQE are wrong after migration and
results in guest kernel-mode encryption services failure.
Comparing the definition of hardware registers, we found that
there was an error when the data read from the register was
combined into an address. Therefore, the address combination
sequence needs to be corrected.
Even after fixing the above problem, we still have an issue
where the Guest from an old kernel can get migrated to
new kernel and may result in wrong data.
In order to ensure that the address is correct after migration,
if an old magic number is detected, the dma address needs to be
updated.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
hisi_acc_vfio_pci: fix XQE dma address error
The dma addresses of EQE and AEQE are wrong after migration and
results in guest kernel-mode encryption services failure.
Comparing the definition of hardware registers, we found that
there was an error when the data read from the register was
combined into an address. Therefore, the address combination
sequence needs to be corrected.
Even after fixing the above problem, we still have an issue
where the Guest from an old kernel can get migrated to
new kernel and may result in wrong data.
In order to ensure that the address is correct after migration,
if an old magic number is detected, the dma address needs to be
updated.
π@cveNotify
π¨ CVE-2025-38159
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds
Set the size to 6 instead of 2, since 'para' array is passed to
'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads
5 bytes:
void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data)
{
...
SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data);
SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1));
...
SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));
Detected using the static analysis tool - Svace.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds
Set the size to 6 instead of 2, since 'para' array is passed to
'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads
5 bytes:
void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data)
{
...
SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data);
SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1));
...
SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));
Detected using the static analysis tool - Svace.
π@cveNotify
π¨ CVE-2025-38160
In the Linux kernel, the following vulnerability has been resolved:
clk: bcm: rpi: Add NULL check in raspberrypi_clk_register()
devm_kasprintf() returns NULL when memory allocation fails. Currently,
raspberrypi_clk_register() does not check for this case, which results
in a NULL pointer dereference.
Add NULL check after devm_kasprintf() to prevent this issue.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
clk: bcm: rpi: Add NULL check in raspberrypi_clk_register()
devm_kasprintf() returns NULL when memory allocation fails. Currently,
raspberrypi_clk_register() does not check for this case, which results
in a NULL pointer dereference.
Add NULL check after devm_kasprintf() to prevent this issue.
π@cveNotify
π¨ CVE-2025-37948
In the Linux kernel, the following vulnerability has been resolved:
arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs
A malicious BPF program may manipulate the branch history to influence
what the hardware speculates will happen next.
On exit from a BPF program, emit the BHB mititgation sequence.
This is only applied for 'classic' cBPF programs that are loaded by
seccomp.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs
A malicious BPF program may manipulate the branch history to influence
what the hardware speculates will happen next.
On exit from a BPF program, emit the BHB mititgation sequence.
This is only applied for 'classic' cBPF programs that are loaded by
seccomp.
π@cveNotify
π¨ CVE-2025-38027
In the Linux kernel, the following vulnerability has been resolved:
regulator: max20086: fix invalid memory access
max20086_parse_regulators_dt() calls of_regulator_match() using an
array of struct of_regulator_match allocated on the stack for the
matches argument.
of_regulator_match() calls devm_of_regulator_put_matches(), which calls
devres_alloc() to allocate a struct devm_of_regulator_matches which will
be de-allocated using devm_of_regulator_put_matches().
struct devm_of_regulator_matches is populated with the stack allocated
matches array.
If the device fails to probe, devm_of_regulator_put_matches() will be
called and will try to call of_node_put() on that stack pointer,
generating the following dmesg entries:
max20086 6-0028: Failed to read DEVICE_ID reg: -121
kobject: '\xc0$\xa5\x03' (000000002cebcb7a): is not initialized, yet
kobject_put() is being called.
Followed by a stack trace matching the call flow described above.
Switch to allocating the matches array using devm_kcalloc() to
avoid accessing the stack pointer long after it's out of scope.
This also has the advantage of allowing multiple max20086 to probe
without overriding the data stored inside the global of_regulator_match.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
regulator: max20086: fix invalid memory access
max20086_parse_regulators_dt() calls of_regulator_match() using an
array of struct of_regulator_match allocated on the stack for the
matches argument.
of_regulator_match() calls devm_of_regulator_put_matches(), which calls
devres_alloc() to allocate a struct devm_of_regulator_matches which will
be de-allocated using devm_of_regulator_put_matches().
struct devm_of_regulator_matches is populated with the stack allocated
matches array.
If the device fails to probe, devm_of_regulator_put_matches() will be
called and will try to call of_node_put() on that stack pointer,
generating the following dmesg entries:
max20086 6-0028: Failed to read DEVICE_ID reg: -121
kobject: '\xc0$\xa5\x03' (000000002cebcb7a): is not initialized, yet
kobject_put() is being called.
Followed by a stack trace matching the call flow described above.
Switch to allocating the matches array using devm_kcalloc() to
avoid accessing the stack pointer long after it's out of scope.
This also has the advantage of allowing multiple max20086 to probe
without overriding the data stored inside the global of_regulator_match.
π@cveNotify
π¨ CVE-2025-38084
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: unshare page tables during VMA split, not before
Currently, __split_vma() triggers hugetlb page table unsharing through
vm_ops->may_split(). This happens before the VMA lock and rmap locks are
taken - which is too early, it allows racing VMA-locked page faults in our
process and racing rmap walks from other processes to cause page tables to
be shared again before we actually perform the split.
Fix it by explicitly calling into the hugetlb unshare logic from
__split_vma() in the same place where THP splitting also happens. At that
point, both the VMA and the rmap(s) are write-locked.
An annoying detail is that we can now call into the helper
hugetlb_unshare_pmds() from two different locking contexts:
1. from hugetlb_split(), holding:
- mmap lock (exclusively)
- VMA lock
- file rmap lock (exclusively)
2. hugetlb_unshare_all_pmds(), which I think is designed to be able to
call us with only the mmap lock held (in shared mode), but currently
only runs while holding mmap lock (exclusively) and VMA lock
Backporting note:
This commit fixes a racy protection that was introduced in commit
b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that
commit claimed to fix an issue introduced in 5.13, but it should actually
also go all the way back.
[jannh@google.com: v2]
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: unshare page tables during VMA split, not before
Currently, __split_vma() triggers hugetlb page table unsharing through
vm_ops->may_split(). This happens before the VMA lock and rmap locks are
taken - which is too early, it allows racing VMA-locked page faults in our
process and racing rmap walks from other processes to cause page tables to
be shared again before we actually perform the split.
Fix it by explicitly calling into the hugetlb unshare logic from
__split_vma() in the same place where THP splitting also happens. At that
point, both the VMA and the rmap(s) are write-locked.
An annoying detail is that we can now call into the helper
hugetlb_unshare_pmds() from two different locking contexts:
1. from hugetlb_split(), holding:
- mmap lock (exclusively)
- VMA lock
- file rmap lock (exclusively)
2. hugetlb_unshare_all_pmds(), which I think is designed to be able to
call us with only the mmap lock held (in shared mode), but currently
only runs while holding mmap lock (exclusively) and VMA lock
Backporting note:
This commit fixes a racy protection that was introduced in commit
b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that
commit claimed to fix an issue introduced in 5.13, but it should actually
also go all the way back.
[jannh@google.com: v2]
π@cveNotify
π¨ CVE-2025-38085
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race
huge_pmd_unshare() drops a reference on a page table that may have
previously been shared across processes, potentially turning it into a
normal page table used in another process in which unrelated VMAs can
afterwards be installed.
If this happens in the middle of a concurrent gup_fast(), gup_fast() could
end up walking the page tables of another process. While I don't see any
way in which that immediately leads to kernel memory corruption, it is
really weird and unexpected.
Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),
just like we do in khugepaged when removing page tables for a THP
collapse.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race
huge_pmd_unshare() drops a reference on a page table that may have
previously been shared across processes, potentially turning it into a
normal page table used in another process in which unrelated VMAs can
afterwards be installed.
If this happens in the middle of a concurrent gup_fast(), gup_fast() could
end up walking the page tables of another process. While I don't see any
way in which that immediately leads to kernel memory corruption, it is
really weird and unexpected.
Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),
just like we do in khugepaged when removing page tables for a THP
collapse.
π@cveNotify