NULL Pointer Dereference Affecting kernel-rt-modules-partner package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
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 applicationsSnyk Learn
Learn about NULL Pointer Dereference vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-RHEL9-KERNELRTMODULESPARTNER-7817457
- published23 Aug 2024
- disclosed22 Aug 2024
Introduced: 22 Aug 2024
CVE-2022-48942 (opens in a new tab)How to fix?
There is no fixed version for RHEL:9 kernel-rt-modules-partner.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-rt-modules-partner package and not the kernel-rt-modules-partner package as distributed by RHEL.
See How to fix? for RHEL:9 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
hwmon: Handle failure to register sensor with thermal zone correctly
If an attempt is made to a sensor with a thermal zone and it fails, the call to devm_thermal_zone_of_sensor_register() may return -ENODEV. This may result in crashes similar to the following.
Unable to handle kernel NULL pointer dereference at virtual address 00000000000003cd ... Internal error: Oops: 96000021 [#1] PREEMPT SMP ... pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mutex_lock+0x18/0x60 lr : thermal_zone_device_update+0x40/0x2e0 sp : ffff800014c4fc60 x29: ffff800014c4fc60 x28: ffff365ee3f6e000 x27: ffffdde218426790 x26: ffff365ee3f6e000 x25: 0000000000000000 x24: ffff365ee3f6e000 x23: ffffdde218426870 x22: ffff365ee3f6e000 x21: 00000000000003cd x20: ffff365ee8bf3308 x19: ffffffffffffffed x18: 0000000000000000 x17: ffffdde21842689c x16: ffffdde1cb7a0b7c x15: 0000000000000040 x14: ffffdde21a4889a0 x13: 0000000000000228 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000001120000 x7 : 0000000000000001 x6 : 0000000000000000 x5 : 0068000878e20f07 x4 : 0000000000000000 x3 : 00000000000003cd x2 : ffff365ee3f6e000 x1 : 0000000000000000 x0 : 00000000000003cd Call trace: mutex_lock+0x18/0x60 hwmon_notify_event+0xfc/0x110 0xffffdde1cb7a0a90 0xffffdde1cb7a0b7c irq_thread_fn+0x2c/0xa0 irq_thread+0x134/0x240 kthread+0x178/0x190 ret_from_fork+0x10/0x20 Code: d503201f d503201f d2800001 aa0103e4 (c8e47c02)
Jon Hunter reports that the exact call sequence is:
hwmon_notify_event() --> hwmon_thermal_notify() --> thermal_zone_device_update() --> update_temperature() --> mutex_lock()
The hwmon core needs to handle all errors returned from calls to devm_thermal_zone_of_sensor_register(). If the call fails with -ENODEV, report that the sensor was not attached to a thermal zone but continue to register the hwmon device.
References
- https://access.redhat.com/security/cve/CVE-2022-48942
- https://git.kernel.org/stable/c/1b5f517cca36292076d9e38fa6e33a257703e62e
- https://git.kernel.org/stable/c/7efe8499cb90651c540753f4269d2d43ede14223
- https://git.kernel.org/stable/c/8a1969e14ad93663f9a3ed02ccc2138da9956a0e
- https://git.kernel.org/stable/c/962b2a3188bfa5388756ffbc47dfa5ff59cb8011