Where
AND
-Infinity
0
Severity
9.8
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

In the Linux kernel, the following vulnerability has been resolved:

nvmet-tcp: add bounds checks in nvmettcpbuildpduiovec

nvmettcpbuildpduiovec() could walk past cmd->req.sg when a PDU length or offset exceeds sgcnt and then use bogus sg->length/offset values, leading to copytoiter() GPF/KASAN. Guard sgidx, remaining entries, and sg->length/offset before building the bvec.

1 / 4
Source: MITRE
First published (updated )
Severity
9.1
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H/E:U

e1000: fix OOB in e1000tbishouldaccept()

1 / 4
Source: Microsoft
First published (updated )
Severity
9.8
Double Free
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix double free of qgroup record after failure to add delayed ref head

In the previous code it was possible to incur into a double kfree() scenario when calling adddelayedrefhead(). This could happen if the record was reported to already exist in the btrfsqgrouptraceextentnolock() call, but then there was an error later on adddelayedrefhead(). In this case, since adddelayedrefhead() returned an error, the caller went to free the record. Since adddelayedrefhead() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee.

The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the adddelayedrefhead(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecordinsertedret' boolean to account for this. Hence, the caller has to kfree the object only if adddelayedrefhead() reports not to have inserted it on the tracing logic.

As a side-effect of the above, we must guarantee that 'qrecordinsertedret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecordinsertedret' having an invalid value on an early exit.

The documentation from the adddelayedrefhead() has also been updated to reflect on the exact ownership of the 'qrecord' object.

1 / 2
Source: MITRE
First published (updated )
Severity
9.8
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

In the Linux kernel, the following vulnerability has been resolved:

veth: reduce XDP nodirect return section to fix race

As explain in commit fa349e396e48 ("veth: Fix race with AFXDP exposing old or uninitialized descriptors") for veth there is a chance after napicompletedone() that another CPU can manage start another NAPI instance running vethpool(). For NAPI this is correctly handled as the napischeduleprep() check will prevent multiple instances from getting scheduled, but for the remaining code in vethpool() this can run concurrent with the newly started NAPI instance.

The problem/race is that xdpclearreturnframenodirect() isn't designed to be nested.

Prior to commit 401cb7dae813 ("net: Reference bpfredirectinfo via taskstruct on PREEMPTRT.") the temporary BPF net context bpfredirectinfo was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' taskstruct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent vethpool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context.

Race is when another CPU gets within the xdpsetreturnframenodirect() section before exiting vethpool() calls the clear-function xdpclearreturnframenodirect().

First published (updated )
Severity
9.2
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

In the Linux kernel, the following vulnerability has been resolved:

libceph: prevent potential out-of-bounds writes in handleauthsessionkey()

The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets.

[ idryomov: changelog ]

1 / 3
Source: NVD
First published (updated )
Severity
9.8
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H/E:U

In the Linux kernel, the following vulnerability has been resolved:

nvmet-fc: avoid scheduling association deletion twice

When forcefully shutting down a port via the configfs interface, nvmetportsubsysdroplink() first calls nvmetportdelctrls() and then nvmetdisableport(). Both functions will eventually schedule all remaining associations for deletion.

The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion.

Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted.

1 / 3
Source: NVD
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203