NULL Pointer Dereference Affecting rv package, versions *


Severity

Recommended
low

Based on CentOS security rating.

Threat Intelligence

EPSS
0.02% (6th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about NULL Pointer Dereference vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-CENTOS9-RV-14496057
  • published18 Dec 2025
  • disclosed16 Dec 2025

Introduced: 16 Dec 2025

CVE-2025-68298  (opens in a new tab)
CWE-476  (opens in a new tab)

How to fix?

There is no fixed version for Centos:9 rv.

NVD Description

Note: Versions mentioned in the description apply only to the upstream rv package and not the rv package as distributed by Centos. See How to fix? for Centos:9 relevant fixed versions and status.

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

Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref

In btusb_mtk_setup(), we set btmtk_data->isopkt_intf to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM)

That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf().

As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf() when btmtk_data->isopkt_intf is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled.

Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL btmtk_data->isopkt_intf the same way it did before the problematic commit (just with a slight change to the error message printed).

CVSS Base Scores

version 3.1