🚨 CVE-2026-43296
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: Workaround SQM/PSE stalls by disabling sticky
NIX SQ manager sticky mode is known to cause stalls when multiple SQs
share an SMQ and transmit concurrently. Additionally, PSE may deadlock
on transitions between sticky and non-sticky transmissions. There is
also a credit drop issue observed when certain condition clocks are
gated.
work around these hardware errata by:
- Disabling SQM sticky operation:
- Clear TM6 (bit 15)
- Clear TM11 (bit 14)
- Disabling sticky → non-sticky transition path that can deadlock PSE:
- Clear TM5 (bit 23)
- Preventing credit drops by keeping the control-flow clock enabled:
- Set TM9 (bit 21)
These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this
configuration the SQM/PSE maintain forward progress under load without
credit loss, at the cost of disabling sticky optimizations.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: Workaround SQM/PSE stalls by disabling sticky
NIX SQ manager sticky mode is known to cause stalls when multiple SQs
share an SMQ and transmit concurrently. Additionally, PSE may deadlock
on transitions between sticky and non-sticky transmissions. There is
also a credit drop issue observed when certain condition clocks are
gated.
work around these hardware errata by:
- Disabling SQM sticky operation:
- Clear TM6 (bit 15)
- Clear TM11 (bit 14)
- Disabling sticky → non-sticky transition path that can deadlock PSE:
- Clear TM5 (bit 23)
- Preventing credit drops by keeping the control-flow clock enabled:
- Set TM9 (bit 21)
These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this
configuration the SQM/PSE maintain forward progress under load without
credit loss, at the cost of disabling sticky optimizations.
🎖@cveNotify
🚨 CVE-2026-43297
In the Linux kernel, the following vulnerability has been resolved:
media: rockchip: rga: Fix possible ERR_PTR dereference in rga_buf_init()
rga_get_frame() can return ERR_PTR(-EINVAL) when buffer type is
unsupported or invalid. rga_buf_init() does not check the return value
and unconditionally dereferences the pointer when accessing f->size.
Add proper ERR_PTR checking and return the error to prevent
dereferencing an invalid pointer.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
media: rockchip: rga: Fix possible ERR_PTR dereference in rga_buf_init()
rga_get_frame() can return ERR_PTR(-EINVAL) when buffer type is
unsupported or invalid. rga_buf_init() does not check the return value
and unconditionally dereferences the pointer when accessing f->size.
Add proper ERR_PTR checking and return the error to prevent
dereferencing an invalid pointer.
🎖@cveNotify
🚨 CVE-2026-37532
AGL agl-service-can-low-level thru 17.1.12 contains a heap buffer over-read in the isotp-c library. In isotp_continue_receive (receive.c:87-89), the payload_length for a Single Frame is extracted from a 4-bit nibble in the CAN frame data, yielding values 0-15. However, a standard CAN frame is only 8 bytes, with payload starting at data[1] (7 bytes available). When payload_length exceeds the available data (e.g., nibble=15 but only 7 payload bytes exist), memcpy(message.payload, &data[1], payload_length) reads up to 8 bytes past the end of the data buffer.
🎖@cveNotify
AGL agl-service-can-low-level thru 17.1.12 contains a heap buffer over-read in the isotp-c library. In isotp_continue_receive (receive.c:87-89), the payload_length for a Single Frame is extracted from a 4-bit nibble in the CAN frame data, yielding values 0-15. However, a standard CAN frame is only 8 bytes, with payload starting at data[1] (7 bytes available). When payload_length exceeds the available data (e.g., nibble=15 but only 7 payload bytes exist), memcpy(message.payload, &data[1], payload_length) reads up to 8 bytes past the end of the data buffer.
🎖@cveNotify
🚨 CVE-2026-43355
In the Linux kernel, the following vulnerability has been resolved:
iio: light: bh1780: fix PM runtime leak on error path
Move pm_runtime_put_autosuspend() before the error check to ensure
the PM runtime reference count is always decremented after
pm_runtime_get_sync(), regardless of whether the read operation
succeeds or fails.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
iio: light: bh1780: fix PM runtime leak on error path
Move pm_runtime_put_autosuspend() before the error check to ensure
the PM runtime reference count is always decremented after
pm_runtime_get_sync(), regardless of whether the read operation
succeeds or fails.
🎖@cveNotify
🚨 CVE-2026-43356
In the Linux kernel, the following vulnerability has been resolved:
iio: imu: adis: Fix NULL pointer dereference in adis_init
The adis_init() function dereferences adis->ops to check if the
individual function pointers (write, read, reset) are NULL, but does
not first check if adis->ops itself is NULL.
Drivers like adis16480, adis16490, adis16545 and others do not set
custom ops and rely on adis_init() assigning the defaults. Since struct
adis is zero-initialized by devm_iio_device_alloc(), adis->ops is NULL
when adis_init() is called, causing a NULL pointer dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
pc : adis_init+0xc0/0x118
Call trace:
adis_init+0xc0/0x118
adis16480_probe+0xe0/0x670
Fix this by checking if adis->ops is NULL before dereferencing it,
falling through to assign the default ops in that case.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
iio: imu: adis: Fix NULL pointer dereference in adis_init
The adis_init() function dereferences adis->ops to check if the
individual function pointers (write, read, reset) are NULL, but does
not first check if adis->ops itself is NULL.
Drivers like adis16480, adis16490, adis16545 and others do not set
custom ops and rely on adis_init() assigning the defaults. Since struct
adis is zero-initialized by devm_iio_device_alloc(), adis->ops is NULL
when adis_init() is called, causing a NULL pointer dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
pc : adis_init+0xc0/0x118
Call trace:
adis_init+0xc0/0x118
adis16480_probe+0xe0/0x670
Fix this by checking if adis->ops is NULL before dereferencing it,
falling through to assign the default ops in that case.
🎖@cveNotify
🚨 CVE-2026-43357
In the Linux kernel, the following vulnerability has been resolved:
iio: gyro: mpu3050-core: fix pm_runtime error handling
The return value of pm_runtime_get_sync() is not checked, allowing
the driver to access hardware that may fail to resume. The device
usage count is also unconditionally incremented. Use
pm_runtime_resume_and_get() which propagates errors and avoids
incrementing the usage count on failure.
In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate()
failure since postdisable does not run when preenable fails.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
iio: gyro: mpu3050-core: fix pm_runtime error handling
The return value of pm_runtime_get_sync() is not checked, allowing
the driver to access hardware that may fail to resume. The device
usage count is also unconditionally incremented. Use
pm_runtime_resume_and_get() which propagates errors and avoids
incrementing the usage count on failure.
In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate()
failure since postdisable does not run when preenable fails.
🎖@cveNotify
🚨 CVE-2026-43358
In the Linux kernel, the following vulnerability has been resolved:
btrfs: add missing RCU unlock in error path in try_release_subpage_extent_buffer()
Call rcu_read_lock() before exiting the loop in
try_release_subpage_extent_buffer() because there is a rcu_read_unlock()
call past the loop.
This has been detected by the Clang thread-safety analyzer.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
btrfs: add missing RCU unlock in error path in try_release_subpage_extent_buffer()
Call rcu_read_lock() before exiting the loop in
try_release_subpage_extent_buffer() because there is a rcu_read_unlock()
call past the loop.
This has been detected by the Clang thread-safety analyzer.
🎖@cveNotify
🚨 CVE-2026-43367
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix a few more NULL pointer dereference in device cleanup
I found a few more paths that cleanup fails due to a NULL version pointer
on unsupported hardware.
Add NULL checks as applicable.
(cherry picked from commit f5a05f8414fc10f307eb965f303580c7778f8dd2)
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix a few more NULL pointer dereference in device cleanup
I found a few more paths that cleanup fails due to a NULL version pointer
on unsupported hardware.
Add NULL checks as applicable.
(cherry picked from commit f5a05f8414fc10f307eb965f303580c7778f8dd2)
🎖@cveNotify
🚨 CVE-2026-43286
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: restore failed global reservations to subpool
Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool")
fixed an underflow error for hstate->resv_huge_pages caused by incorrectly
attributing globally requested pages to the subpool's reservation.
Unfortunately, this fix also introduced the opposite problem, which would
leave spool->used_hpages elevated if the globally requested pages could
not be acquired. This is because while a subpool's reserve pages only
accounts for what is requested and allocated from the subpool, its "used"
counter keeps track of what is consumed in total, both from the subpool
and globally. Thus, we need to adjust spool->used_hpages in the other
direction, and make sure that globally requested pages are uncharged from
the subpool's used counter.
Each failed allocation attempt increments the used_hpages counter by how
many pages were requested from the global pool. Ultimately, this renders
the subpool unusable, as used_hpages approaches the max limit.
The issue can be reproduced as follows:
1. Allocate 4 hugetlb pages
2. Create a hugetlb mount with max=4, min=2
3. Consume 2 pages globally
4. Request 3 pages from the subpool (2 from subpool + 1 from global)
4.1 hugepage_subpool_get_pages(spool, 3) succeeds.
used_hpages += 3
4.2 hugetlb_acct_memory(h, 1) fails: no global pages left
used_hpages -= 2
5. Subpool now has used_hpages = 1, despite not being able to
successfully allocate any hugepages. It believes it can now only
allocate 3 more hugepages, not 4.
With each failed allocation attempt incrementing the used counter, the
subpool eventually reaches a point where its used counter equals its
max counter. At that point, any future allocations that try to
allocate hugeTLB pages from the subpool will fail, despite the subpool
not having any of its hugeTLB pages consumed by any user.
Once this happens, there is no way to make the subpool usable again,
since there is no way to decrement the used counter as no process is
really consuming the hugeTLB pages.
The underflow issue that the original commit fixes still remains fixed
as well.
Without this fix, used_hpages would keep on leaking if
hugetlb_acct_memory() fails.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: restore failed global reservations to subpool
Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool")
fixed an underflow error for hstate->resv_huge_pages caused by incorrectly
attributing globally requested pages to the subpool's reservation.
Unfortunately, this fix also introduced the opposite problem, which would
leave spool->used_hpages elevated if the globally requested pages could
not be acquired. This is because while a subpool's reserve pages only
accounts for what is requested and allocated from the subpool, its "used"
counter keeps track of what is consumed in total, both from the subpool
and globally. Thus, we need to adjust spool->used_hpages in the other
direction, and make sure that globally requested pages are uncharged from
the subpool's used counter.
Each failed allocation attempt increments the used_hpages counter by how
many pages were requested from the global pool. Ultimately, this renders
the subpool unusable, as used_hpages approaches the max limit.
The issue can be reproduced as follows:
1. Allocate 4 hugetlb pages
2. Create a hugetlb mount with max=4, min=2
3. Consume 2 pages globally
4. Request 3 pages from the subpool (2 from subpool + 1 from global)
4.1 hugepage_subpool_get_pages(spool, 3) succeeds.
used_hpages += 3
4.2 hugetlb_acct_memory(h, 1) fails: no global pages left
used_hpages -= 2
5. Subpool now has used_hpages = 1, despite not being able to
successfully allocate any hugepages. It believes it can now only
allocate 3 more hugepages, not 4.
With each failed allocation attempt incrementing the used counter, the
subpool eventually reaches a point where its used counter equals its
max counter. At that point, any future allocations that try to
allocate hugeTLB pages from the subpool will fail, despite the subpool
not having any of its hugeTLB pages consumed by any user.
Once this happens, there is no way to make the subpool usable again,
since there is no way to decrement the used counter as no process is
really consuming the hugeTLB pages.
The underflow issue that the original commit fixes still remains fixed
as well.
Without this fix, used_hpages would keep on leaking if
hugetlb_acct_memory() fails.
🎖@cveNotify
🚨 CVE-2026-43287
In the Linux kernel, the following vulnerability has been resolved:
drm: Account property blob allocations to memcg
DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized
property blobs backed by kernel memory.
Currently, the blob data allocation is not accounted to the allocating
process's memory cgroup, allowing unprivileged users to trigger unbounded
kernel memory consumption and potentially cause system-wide OOM.
Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory
is properly charged to the caller's memcg. This ensures existing cgroup
memory limits apply and prevents uncontrolled kernel memory growth without
introducing additional policy or per-file limits.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
drm: Account property blob allocations to memcg
DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized
property blobs backed by kernel memory.
Currently, the blob data allocation is not accounted to the allocating
process's memory cgroup, allowing unprivileged users to trigger unbounded
kernel memory consumption and potentially cause system-wide OOM.
Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory
is properly charged to the caller's memcg. This ensures existing cgroup
memory limits apply and prevents uncontrolled kernel memory growth without
introducing additional policy or per-file limits.
🎖@cveNotify
🚨 CVE-2026-41483
OpenTelemetry.Resources.Azure is the .NET resource detector for Azure environments. In versions 1.15.0-beta.1 and earlier, the AzureVmMetaDataRequestor class makes HTTP requests to the Azure VM instance metadata service and reads the response body into memory without any size limit. An attacker who controls the configured endpoint, or who can intercept traffic to it via a man-in-the-middle attack, can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an OutOfMemoryException that terminates the process. As a workaround, disable the Azure VM resource detector or use network-level controls such as firewall rules, mTLS, or a service mesh to prevent man-in-the-middle attacks on the Azure VM instance metadata endpoint. This issue is fixed in version 1.15.1-beta.1, which streams responses rather than buffering them entirely in memory and ignores responses larger than 4 MiB.
🎖@cveNotify
OpenTelemetry.Resources.Azure is the .NET resource detector for Azure environments. In versions 1.15.0-beta.1 and earlier, the AzureVmMetaDataRequestor class makes HTTP requests to the Azure VM instance metadata service and reads the response body into memory without any size limit. An attacker who controls the configured endpoint, or who can intercept traffic to it via a man-in-the-middle attack, can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an OutOfMemoryException that terminates the process. As a workaround, disable the Azure VM resource detector or use network-level controls such as firewall rules, mTLS, or a service mesh to prevent man-in-the-middle attacks on the Azure VM instance metadata endpoint. This issue is fixed in version 1.15.1-beta.1, which streams responses rather than buffering them entirely in memory and ignores responses larger than 4 MiB.
🎖@cveNotify
GitHub
[Resources.Azure] Limit response body size read by martincostello · Pull Request #4121 · open-telemetry/opentelemetry-dotnet-contrib
Changes
Limit the length of the HTTP response body that is read from the Azure VM instance metadata service.
Merge requirement checklist
CONTRIBUTING guidelines followed (license requirements, nu...
Limit the length of the HTTP response body that is read from the Azure VM instance metadata service.
Merge requirement checklist
CONTRIBUTING guidelines followed (license requirements, nu...
🚨 CVE-2026-41484
OpenTelemetry.Exporter.OneCollector is a .NET exporter that sends telemetry to a OneCollector back-end over HTTP. In versions 1.15.0 and earlier, when a request to the configured back-end or collector results in an unsuccessful HTTP 4xx or 5xx response, the HttpJsonPostTransport class reads the entire response body into memory with no upper bound on the number of bytes consumed in order to include the error response in operator logs.
An attacker who controls the configured endpoint, or who can intercept traffic to it via a man-in-the-middle attack, can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an OutOfMemoryException that terminates the process. As a workaround, use network-level controls such as firewall rules, mTLS, or a service mesh to prevent man-in-the-middle attacks on the configured back-end or collector endpoint. This issue is fixed in version 1.15.1, which limits the number of bytes read from the response body in an error condition to 4 MiB.
🎖@cveNotify
OpenTelemetry.Exporter.OneCollector is a .NET exporter that sends telemetry to a OneCollector back-end over HTTP. In versions 1.15.0 and earlier, when a request to the configured back-end or collector results in an unsuccessful HTTP 4xx or 5xx response, the HttpJsonPostTransport class reads the entire response body into memory with no upper bound on the number of bytes consumed in order to include the error response in operator logs.
An attacker who controls the configured endpoint, or who can intercept traffic to it via a man-in-the-middle attack, can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an OutOfMemoryException that terminates the process. As a workaround, use network-level controls such as firewall rules, mTLS, or a service mesh to prevent man-in-the-middle attacks on the configured back-end or collector endpoint. This issue is fixed in version 1.15.1, which limits the number of bytes read from the response body in an error condition to 4 MiB.
🎖@cveNotify
GitHub
[OneCollector] Limit response body size read by martincostello · Pull Request #4117 · open-telemetry/opentelemetry-dotnet-contrib
Changes
Limit the length of the HTTP response body that is read by HttpJsonPostTransport.
Merge requirement checklist
CONTRIBUTING guidelines followed (license requirements, nullable enabled, sta...
Limit the length of the HTTP response body that is read by HttpJsonPostTransport.
Merge requirement checklist
CONTRIBUTING guidelines followed (license requirements, nullable enabled, sta...
🚨 CVE-2026-43312
In the Linux kernel, the following vulnerability has been resolved:
media: i2c: ov5647: Initialize subdev before controls
In ov5647_init_controls() we call v4l2_get_subdevdata, but it is
initialized by v4l2_i2c_subdev_init() in the probe, which currently
happens after init_controls(). This can result in a segfault if the
error condition is hit, and we try to access i2c_client, so fix the
order.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
media: i2c: ov5647: Initialize subdev before controls
In ov5647_init_controls() we call v4l2_get_subdevdata, but it is
initialized by v4l2_i2c_subdev_init() in the probe, which currently
happens after init_controls(). This can result in a segfault if the
error condition is hit, and we try to access i2c_client, so fix the
order.
🎖@cveNotify
🚨 CVE-2026-43313
In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4()
In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE
device and then reassigned an ISA device:
dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...);
dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...);
If the first lookup succeeds but the second fails, dev becomes NULL. This
leads to a potential null-pointer dereference when dev_dbg() is called:
if (errata.piix4.bmisx)
dev_dbg(&dev->dev, ...);
To prevent this, use two temporary pointers and retrieve each device
independently, avoiding overwriting dev with a possible NULL value.
[ rjw: Subject adjustment, added an empty code line ]
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4()
In acpi_processor_errata_piix4(), the pointer dev is first assigned an IDE
device and then reassigned an ISA device:
dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB, ...);
dev = pci_get_subsys(..., PCI_DEVICE_ID_INTEL_82371AB_0, ...);
If the first lookup succeeds but the second fails, dev becomes NULL. This
leads to a potential null-pointer dereference when dev_dbg() is called:
if (errata.piix4.bmisx)
dev_dbg(&dev->dev, ...);
To prevent this, use two temporary pointers and retrieve each device
independently, avoiding overwriting dev with a possible NULL value.
[ rjw: Subject adjustment, added an empty code line ]
🎖@cveNotify
🚨 CVE-2024-0193
A use-after-free flaw was found in the netfilter subsystem of the Linux kernel. If the catchall element is garbage-collected when the pipapo set is removed, the element can be deactivated twice. This can cause a use-after-free issue on an NFT_CHAIN object or NFT_OBJECT object, allowing a local unprivileged user with CAP_NET_ADMIN capability to escalate their privileges on the system.
🎖@cveNotify
A use-after-free flaw was found in the netfilter subsystem of the Linux kernel. If the catchall element is garbage-collected when the pipapo set is removed, the element can be deactivated twice. This can cause a use-after-free issue on an NFT_CHAIN object or NFT_OBJECT object, allowing a local unprivileged user with CAP_NET_ADMIN capability to escalate their privileges on the system.
🎖@cveNotify
🚨 CVE-2026-43309
In the Linux kernel, the following vulnerability has been resolved:
md raid: fix hang when stopping arrays with metadata through dm-raid
When using device-mapper's dm-raid target, stopping a RAID array can cause
the system to hang under specific conditions.
This occurs when:
- A dm-raid managed device tree is suspended from top to bottom
(the top-level RAID device is suspended first, followed by its
underlying metadata and data devices)
- The top-level RAID device is then removed
Removing the top-level device triggers a hang in the following sequence:
the dm-raid destructor calls md_stop(), which tries to flush the
write-intent bitmap by writing to the metadata sub-devices. However, these
devices are already suspended, making them unable to complete the write-intent
operations and causing an indefinite block.
Fix:
- Prevent bitmap flushing when md_stop() is called from dm-raid
destructor context
and avoid a quiescing/unquescing cycle which could also cause I/O
- Still allow write-intent bitmap flushing when called from dm-raid
suspend context
This ensures that RAID array teardown can complete successfully even when the
underlying devices are in a suspended state.
This second patch uses md_is_rdwr() to distinguish between suspend and
destructor paths as elaborated on above.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
md raid: fix hang when stopping arrays with metadata through dm-raid
When using device-mapper's dm-raid target, stopping a RAID array can cause
the system to hang under specific conditions.
This occurs when:
- A dm-raid managed device tree is suspended from top to bottom
(the top-level RAID device is suspended first, followed by its
underlying metadata and data devices)
- The top-level RAID device is then removed
Removing the top-level device triggers a hang in the following sequence:
the dm-raid destructor calls md_stop(), which tries to flush the
write-intent bitmap by writing to the metadata sub-devices. However, these
devices are already suspended, making them unable to complete the write-intent
operations and causing an indefinite block.
Fix:
- Prevent bitmap flushing when md_stop() is called from dm-raid
destructor context
and avoid a quiescing/unquescing cycle which could also cause I/O
- Still allow write-intent bitmap flushing when called from dm-raid
suspend context
This ensures that RAID array teardown can complete successfully even when the
underlying devices are in a suspended state.
This second patch uses md_is_rdwr() to distinguish between suspend and
destructor paths as elaborated on above.
🎖@cveNotify
🚨 CVE-2026-43310
In the Linux kernel, the following vulnerability has been resolved:
media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC
For the i.MX8MQ platform, there is a hardware limitation: the g1 VPU and
g2 VPU cannot decode simultaneously; otherwise, it will cause below bus
error and produce corrupted pictures, even potentially lead to system hang.
[ 110.527986] hantro-vpu 38310000.video-codec: frame decode timed out.
[ 110.583517] hantro-vpu 38310000.video-codec: bus error detected.
Therefore, it is necessary to ensure that g1 and g2 operate alternately.
This allows for successful multi-instance decoding of H.264 and HEVC.
To achieve this, g1 and g2 share the same v4l2_m2m_dev, and then the
v4l2_m2m_dev can handle the scheduling.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC
For the i.MX8MQ platform, there is a hardware limitation: the g1 VPU and
g2 VPU cannot decode simultaneously; otherwise, it will cause below bus
error and produce corrupted pictures, even potentially lead to system hang.
[ 110.527986] hantro-vpu 38310000.video-codec: frame decode timed out.
[ 110.583517] hantro-vpu 38310000.video-codec: bus error detected.
Therefore, it is necessary to ensure that g1 and g2 operate alternately.
This allows for successful multi-instance decoding of H.264 and HEVC.
To achieve this, g1 and g2 share the same v4l2_m2m_dev, and then the
v4l2_m2m_dev can handle the scheduling.
🎖@cveNotify
🚨 CVE-2026-43311
In the Linux kernel, the following vulnerability has been resolved:
soc/tegra: pmc: Fix unsafe generic_handle_irq() call
Currently, when resuming from system suspend on Tegra platforms,
the following warning is observed:
WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666
Call trace:
handle_irq_desc+0x20/0x58 (P)
tegra186_pmc_wake_syscore_resume+0xe4/0x15c
syscore_resume+0x3c/0xb8
suspend_devices_and_enter+0x510/0x540
pm_suspend+0x16c/0x1d8
The warning occurs because generic_handle_irq() is being called from
a non-interrupt context which is considered as unsafe.
Fix this warning by deferring generic_handle_irq() call to an IRQ work
which gets executed in hard IRQ context where generic_handle_irq()
can be called safely.
When PREEMPT_RT kernels are used, regular IRQ work (initialized with
init_irq_work) is deferred to run in per-CPU kthreads in preemptible
context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD
variant so that with PREEMPT_RT kernels, the IRQ work is processed in
hardirq context instead of being deferred to a thread which is required
for calling generic_handle_irq().
On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD()
execute in IRQ context, so this change has no functional impact for
standard kernel configurations.
[treding@nvidia.com: miscellaneous cleanups]
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
soc/tegra: pmc: Fix unsafe generic_handle_irq() call
Currently, when resuming from system suspend on Tegra platforms,
the following warning is observed:
WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666
Call trace:
handle_irq_desc+0x20/0x58 (P)
tegra186_pmc_wake_syscore_resume+0xe4/0x15c
syscore_resume+0x3c/0xb8
suspend_devices_and_enter+0x510/0x540
pm_suspend+0x16c/0x1d8
The warning occurs because generic_handle_irq() is being called from
a non-interrupt context which is considered as unsafe.
Fix this warning by deferring generic_handle_irq() call to an IRQ work
which gets executed in hard IRQ context where generic_handle_irq()
can be called safely.
When PREEMPT_RT kernels are used, regular IRQ work (initialized with
init_irq_work) is deferred to run in per-CPU kthreads in preemptible
context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD
variant so that with PREEMPT_RT kernels, the IRQ work is processed in
hardirq context instead of being deferred to a thread which is required
for calling generic_handle_irq().
On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD()
execute in IRQ context, so this change has no functional impact for
standard kernel configurations.
[treding@nvidia.com: miscellaneous cleanups]
🎖@cveNotify
🚨 CVE-2026-43326
In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Fix SCX_KICK_WAIT deadlock by deferring wait to balance callback
SCX_KICK_WAIT busy-waits in kick_cpus_irq_workfn() using
smp_cond_load_acquire() until the target CPU's kick_sync advances. Because
the irq_work runs in hardirq context, the waiting CPU cannot reschedule and
its own kick_sync never advances. If multiple CPUs form a wait cycle, all
CPUs deadlock.
Replace the busy-wait in kick_cpus_irq_workfn() with resched_curr() to
force the CPU through do_pick_task_scx(), which queues a balance callback
to perform the wait. The balance callback drops the rq lock and enables
IRQs following the sched_core_balance() pattern, so the CPU can process
IPIs while waiting. The local CPU's kick_sync is advanced on entry to
do_pick_task_scx() and continuously during the wait, ensuring any CPU that
starts waiting for us sees the advancement and cannot form cyclic
dependencies.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Fix SCX_KICK_WAIT deadlock by deferring wait to balance callback
SCX_KICK_WAIT busy-waits in kick_cpus_irq_workfn() using
smp_cond_load_acquire() until the target CPU's kick_sync advances. Because
the irq_work runs in hardirq context, the waiting CPU cannot reschedule and
its own kick_sync never advances. If multiple CPUs form a wait cycle, all
CPUs deadlock.
Replace the busy-wait in kick_cpus_irq_workfn() with resched_curr() to
force the CPU through do_pick_task_scx(), which queues a balance callback
to perform the wait. The balance callback drops the rq lock and enables
IRQs following the sched_core_balance() pattern, so the CPU can process
IPIs while waiting. The local CPU's kick_sync is advanced on entry to
do_pick_task_scx() and continuously during the wait, ensuring any CPU that
starts waiting for us sees the advancement and cannot form cyclic
dependencies.
🎖@cveNotify
🚨 CVE-2026-43327
In the Linux kernel, the following vulnerability has been resolved:
USB: dummy-hcd: Fix locking/synchronization error
Syzbot testing was able to provoke an addressing exception and crash
in the usb_gadget_udc_reset() routine in
drivers/usb/gadgets/udc/core.c, resulting from the fact that the
routine was called with a second ("driver") argument of NULL. The bad
caller was set_link_state() in dummy_hcd.c, and the problem arose
because of a race between a USB reset and driver unbind.
These sorts of races were not supposed to be possible; commit
7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"),
along with a few followup commits, was written specifically to prevent
them. As it turns out, there are (at least) two errors remaining in
the code. Another patch will address the second error; this one is
concerned with the first.
The error responsible for the syzbot crash occurred because the
stop_activity() routine will sometimes drop and then re-acquire the
dum->lock spinlock. A call to stop_activity() occurs in
set_link_state() when handling an emulated USB reset, after the test
of dum->ints_enabled and before the increment of dum->callback_usage.
This allowed another thread (doing a driver unbind) to sneak in and
grab the spinlock, and then clear dum->ints_enabled and dum->driver.
Normally this other thread would have to wait for dum->callback_usage
to go down to 0 before it would clear dum->driver, but in this case it
didn't have to wait since dum->callback_usage had not yet been
incremented.
The fix is to increment dum->callback_usage _before_ calling
stop_activity() instead of after. Then the thread doing the unbind
will not clear dum->driver until after the call to
usb_gadget_udc_reset() safely returns and dum->callback_usage has been
decremented again.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
USB: dummy-hcd: Fix locking/synchronization error
Syzbot testing was able to provoke an addressing exception and crash
in the usb_gadget_udc_reset() routine in
drivers/usb/gadgets/udc/core.c, resulting from the fact that the
routine was called with a second ("driver") argument of NULL. The bad
caller was set_link_state() in dummy_hcd.c, and the problem arose
because of a race between a USB reset and driver unbind.
These sorts of races were not supposed to be possible; commit
7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"),
along with a few followup commits, was written specifically to prevent
them. As it turns out, there are (at least) two errors remaining in
the code. Another patch will address the second error; this one is
concerned with the first.
The error responsible for the syzbot crash occurred because the
stop_activity() routine will sometimes drop and then re-acquire the
dum->lock spinlock. A call to stop_activity() occurs in
set_link_state() when handling an emulated USB reset, after the test
of dum->ints_enabled and before the increment of dum->callback_usage.
This allowed another thread (doing a driver unbind) to sneak in and
grab the spinlock, and then clear dum->ints_enabled and dum->driver.
Normally this other thread would have to wait for dum->callback_usage
to go down to 0 before it would clear dum->driver, but in this case it
didn't have to wait since dum->callback_usage had not yet been
incremented.
The fix is to increment dum->callback_usage _before_ calling
stop_activity() instead of after. Then the thread doing the unbind
will not clear dum->driver until after the call to
usb_gadget_udc_reset() safely returns and dum->callback_usage has been
decremented again.
🎖@cveNotify
👍1
🚨 CVE-2026-43316
In the Linux kernel, the following vulnerability has been resolved:
media: solo6x10: Check for out of bounds chip_id
Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type
(literal "1" is an "int") could end up being shifted beyond 32 bits,
so instrumentation was added (and due to the double is_tw286x() call
seen via inlining), Clang decides the second one must now be undefined
behavior and elides the rest of the function[1]. This is a known problem
with Clang (that is still being worked on), but we can avoid the entire
problem by actually checking the existing max chip ID, and now there is
no runtime instrumentation added at all since everything is known to be
within bounds.
Additionally use an unsigned value for the shift to remove the
instrumentation even without the explicit bounds checking.
[hverkuil: fix checkpatch warning for is_tw286x]
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
media: solo6x10: Check for out of bounds chip_id
Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type
(literal "1" is an "int") could end up being shifted beyond 32 bits,
so instrumentation was added (and due to the double is_tw286x() call
seen via inlining), Clang decides the second one must now be undefined
behavior and elides the rest of the function[1]. This is a known problem
with Clang (that is still being worked on), but we can avoid the entire
problem by actually checking the existing max chip ID, and now there is
no runtime instrumentation added at all since everything is known to be
within bounds.
Additionally use an unsigned value for the shift to remove the
instrumentation even without the explicit bounds checking.
[hverkuil: fix checkpatch warning for is_tw286x]
🎖@cveNotify