Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 device_link_remove+0x3c/0xa0 _regulator_put.part.0+0x168/0x190 regulator_put+0x3c/0x54 devm_regulator_release+0x14/0x20 -> #1 (regulator_list_mutex){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 regulator_lock_dependent+0x54/0x284 regulator_enable+0x34/0x80 phy_power_on+0x24/0x130 __dwc2_lowlevel_hw_enable+0x100/0x130 dwc2_lowlevel_hw_enable+0x18/0x40 dwc2_hsotg_udc_start+0x6c/0x2f0 gadget_bind_driver+0x124/0x1f4 -> #0 (udc_lock){+.+.}-{3:3}: __lock_acquire+0x1298/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nes
_lock_acquire+0x1298/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 usb_udc_uevent+0x54/0xe0 Evidently this was caused by the scope of udc_mutex being too large. The mutex is only meant to protect udc->driver along with a few other things. As far as I can tell, there's no reason for the mutex to be held while the gadget core calls a gadget driver's ->bind or ->unbind routine, or while a UDC is being started or stopped. (This accounts for link #1 in the chain above, where the mutex is held while the dwc2_hsotg_udc is started as part of driver probing.) Gadget drivers' ->disconnect callbacks are problematic. Even though usb_gadg
_udc is started as part of driver probing.) Gadget drivers' ->disconnect callbacks are problematic. Even though usb_gadget_disconnect() will now acquire the udc_mutex, there's a window in usb_gadget_bind_driver() between the times when the mutex is released and the ->bind callback is invoked. If a disconnect occurred during that window, we could call the driver's ->disconnect routine before its ->bind routine. To prevent this from happening, it will be necessary to prevent a UDC from connecting while it has no gadget driver. This should be done already but it doesn't seem to be; currently usb_gadget_connect() has no check for this. Such a check will have to be added later. Some degree of mut
o be; currently usb_gadget_connect() has no check for this. Such a check will have to be added later. Some degree of mutual exclusion is required in soft_connect_store(), which can dereference udc->driver at arbitrary times since it is a sysfs callback. The solution here is to acquire the gadget's device lock rather than the udc_mutex. Since the driver core guarantees that the device lock is always held during driver binding and unbinding, this will make the accesses in soft_connect_store() mutually exclusive with any changes to udc->driver. Lastly, it turns out there is one place which should hold the udc_mutex but currently does not: The function_show() routine needs protection while it de
e place which should hold the udc_mutex but currently does not: The function_show() routine needs protection while it dereferences udc->driver. The missing lock and unlock calls are added. References: - https://git.kernel.org/stable/c/1a065e4673cbdd9f222a05f85e17d78ea50c8d9c - https://git.kernel.org/stable/c/1016fc0c096c92dd0e6e0541daac7a7868169903
CVE ID: CVE-2022-49944 State: PUBLISHED Published: 2025-06-18T10:59:59.319Z Last Updated: 2025-06-18T10:59:59.319Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Revert "usb: typec: ucsi: add a common function ucsi_unregister_connectors()" The recent commit 87d0e2f41b8c ("usb: typec: ucsi: add a common function ucsi_unregister_connectors()") introduced a regression that caused NULL dereference at reading the power supply sysfs. It's a stale sysfs entry that should have been removed but remains with NULL ops. The commit changed the error handling to skip the entries after a NULL con->wq, and this leaves the power device unreleas
he commit changed the error handling to skip the entries after a NULL con->wq, and this leaves the power device unreleased. For addressing the regression, the straight revert is applied here. Further code improvements can be done from the scratch again. References: - https://git.kernel.org/stable/c/3d4044c9e6d2e3f11f1f8b5e0ee8647d3eb1afad - https://git.kernel.org/stable/c/5f73aa2cf8bef4a39baa1591c3144ede4788826e
CVE ID: CVE-2022-49945 State: PUBLISHED Published: 2025-06-18T11:00:01.037Z Last Updated: 2025-06-18T11:00:01.037Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: hwmon: (gpio-fan) Fix array out of bounds access The driver does not check if the cooling state passed to gpio_fan_set_cur_state() exceeds the maximum cooling state as stored in fan_data->num_speeds. Since the cooling state is later used as an array index in set_fan_speed(), an array out of bounds access can occur. This can be exploited by setting the state of the thermal cooling device to arbitrary values, causing for example a kernel oops when unavailable memory is a
state of the thermal cooling device to arbitrary values, causing for example a kernel oops when unavailable memory is accessed this way. Example kernel oops: [ 807.987276] Unable to handle kernel paging request at virtual address ffffff80d0588064 [ 807.987369] Mem abort info: [ 807.987398] ESR = 0x96000005 [ 807.987428] EC = 0x25: DABT (current EL), IL = 32 bits [ 807.987477] SET = 0, FnV = 0 [ 807.987507] EA = 0, S1PTW = 0 [ 807.987536] FSC = 0x05: level 1 translation fault [ 807.987570] Data abort info: [ 807.987763] ISV = 0, ISS = 0x00000005 [ 807.987801] CM = 0, WnR = 0 [ 807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000 [ 807.987872] [ffffff80d0588064] pgd=000000
0 [ 807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000 [ 807.987872] [ffffff80d0588064] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 807.987961] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 807.987992] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec brcmfmac vc4 brcmutil cec drm_kms_helper snd_soc_core cfg80211 snd_compress bcm2835_codec(C) snd_pcm_dmaengine syscopyarea bcm2835_isp(C) bcm2835_v4l2(C) sysfillrect v4l2_mem2mem bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops
m bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops rfkill videobuf2_v4l2 videobuf2_common i2c_bcm2835 snd_bcm2835(C) videodev snd_pcm snd_timer snd mc vc_sm_cma(C) gpio_fan uio_pdrv_genirq uio drm fuse drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 807.988508] CPU: 0 PID: 1321 Comm: bash Tainted: G C 5.15.56-v8+ #1575 [ 807.988548] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 807.988574] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 807.988608] pc : set_fan_speed.part.5+0x34/0x80 [gpio_fan] [ 807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan] [ 807.988691] sp : ffffffc
ed.part.5+0x34/0x80 [gpio_fan] [ 807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan] [ 807.988691] sp : ffffffc008cf3bd0 [ 807.988710] x29: ffffffc008cf3bd0 x28: ffffff80019edac0 x27: 0000000000000000 [ 807.988762] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800747c920 [ 807.988787] x23: 000000000000000a x22: ffffff800369f000 x21: 000000001999997c [ 807.988854] x20: ffffff800369f2e8 x19: ffffff8002ae8080 x18: 0000000000000000 [ 807.988877] x17: 0000000000000000 x16: 0000000000000000 x15: 000000559e271b70 [ 807.988938] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c [ 807.9890
0000000 x12: 0000000000000000 [ 807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c [ 807.989018] x8 : 000000000000000a x7 : 00000000ffffffc9 x6 : 0000000000000009 [ 807.989040] x5 : 000000000000002a x4 : 0000000000000000 x3 : ffffff800369f2e8 [ 807.989062] x2 : 000000000000e780 x1 : 0000000000000001 x0 : ffffff80d0588060 [ 807.989084] Call trace: [ 807.989091] set_fan_speed.part.5+0x34/0x80 [gpio_fan] [ 807.989113] gpio_fan_set_cur_state+0x34/0x50 [gpio_fan] [ 807.989199] cur_state_store+0x84/0xd0 [ 807.989221] dev_attr_store+0x20/0x38 [ 807.989262] sysfs_kf_write+0x4c/0x60 [ 807.989282] kernfs_fop_write_iter+0x130/0x1c0 [ 807.989298] new_sync_write+0x10c/0x190 [ 8
2] sysfs_kf_write+0x4c/0x60 [ 807.989282] kernfs_fop_write_iter+0x130/0x1c0 [ 807.989298] new_sync_write+0x10c/0x190 [ 807.989315] vfs_write+0x254/0x378 [ 807.989362] ksys_write+0x70/0xf8 [ 807.989379] __arm64_sys_write+0x24/0x30 [ 807.989424] invoke_syscall+0x4c/0x110 [ 807.989442] el0_svc_common.constprop.3+0xfc/0x120 [ 807.989458] do_el0_svc+0x2c/0x90 [ 807.989473] el0_svc+0x24/0x60 [ 807.989544] el0t_64_sync_handler+0x90/0xb8 [ 807.989558] el0t_64_sync+0x1a0/0x1a4 [ 807.989579] Code: b9403801 f9402800 7100003f 8b35cc00 (b9400416) [ 807.989627] ---[ end t ---truncated--- References: - https://git.kernel.org/stable/c/e9f6972ab40a82bd7f6d36800792ba2e084474d8 - https://git.kernel.org/stable/
References: - https://git.kernel.org/stable/c/e9f6972ab40a82bd7f6d36800792ba2e084474d8 - https://git.kernel.org/stable/c/3ff866455e1e263a9ac1958095fd440984248e2f - https://git.kernel.org/stable/c/c8ae6a18708f260ccdeef6ba53af7548457dc26c - https://git.kernel.org/stable/c/7756eb1ed124753f4d64f761fc3d84290dffcb4d - https://git.kernel.org/stable/c/517dba798793e69b510779c3cde7224a65f3ed1d - https://git.kernel.org/stable/c/53196e0376205ed49b75bfd0475af5e0fbd20156 - https://git.kernel.org/stable/c/3263984c7acdcb0658155b05a724ed45a10de76d - https://git.kernel.org/stable/c/f233d2be38dbbb22299192292983037f01ab363c
CVE ID: CVE-2022-49946 State: PUBLISHED Published: 2025-06-18T11:00:07.966Z Last Updated: 2025-06-18T11:00:07.966Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: bcm: rpi: Prevent out-of-bounds access The while loop in raspberrypi_discover_clocks() relies on the assumption that the id of the last clock element is zero. Because this data comes from the Videocore firmware and it doesn't guarantuee such a behavior this could lead to out-of-bounds access. So fix this by providing a sentinel element. References: - https://git.kernel.org/stable/c/fcae47b2d23c81603b01f56cf8db63ed64599d34 - https://git.kernel.org/stable/c/ff0b144d
s: - https://git.kernel.org/stable/c/fcae47b2d23c81603b01f56cf8db63ed64599d34 - https://git.kernel.org/stable/c/ff0b144d4b0a9fbd6efe4d2c0a4b6c9bae2138d2 - https://git.kernel.org/stable/c/c8b04b731d43366824841ebdca4ac715f95e0ea4 - https://git.kernel.org/stable/c/bc163555603e4ae9c817675ad80d618a4cdbfa2d
CVE ID: CVE-2022-49947 State: PUBLISHED Published: 2025-06-18T11:00:11.012Z Last Updated: 2025-06-18T11:00:11.012Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: binder: fix alloc->vma_vm_mm null-ptr dereference Syzbot reported a couple issues introduced by commit 44e602b4e52f ("binder_alloc: add missing mmap_lock calls when using the VMA"), in which we attempt to acquire the mmap_lock when alloc->vma_vm_mm has not been initialized yet. This can happen if a binder_proc receives a transaction without having previously called mmap() to setup the binder_proc->alloc space in [1]. Also, a similar issue occurs via binder_alloc_print_
viously called mmap() to setup the binder_proc->alloc space in [1]. Also, a similar issue occurs via binder_alloc_print_pages() when we try to dump the debugfs binder stats file in [2]. Sample of syzbot's crash report: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 PID: 3755 Comm: syz-executor229 Not tainted 6.0.0-rc1-next-20220819-syzkaller #0 syz-executor229[3755] cmdline: ./syz-executor2294415195 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 RIP: 0010:__lock_acquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923 [...] Call Trace: <TASK> lock_acquire ker
07/22/2022 RIP: 0010:__lock_acquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923 [...] Call Trace: <TASK> lock_acquire kernel/locking/lockdep.c:5666 [inline] lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631 down_read+0x98/0x450 kernel/locking/rwsem.c:1499 mmap_read_lock include/linux/mmap_lock.h:117 [inline] binder_alloc_new_buf_locked drivers/android/binder_alloc.c:405 [inline] binder_alloc_new_buf+0xa5/0x19e0 drivers/android/binder_alloc.c:593 binder_transaction+0x242e/0x9a80 drivers/android/binder.c:3199 binder_thread_write+0x664/0x3220 drivers/android/binder.c:3986 binder_ioctl_write_read drivers/android/binder.c:5036 [inline] binder_ioctl+0x3470/0x6d00 drivers/android/binder.c:5323
binder_ioctl_write_read drivers/android/binder.c:5036 [inline] binder_ioctl+0x3470/0x6d00 drivers/android/binder.c:5323 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] ================================================================== Fix these issues by setting up alloc->vma_vm_mm pointer during open() and caching directly from current->mm. This guarantees we have a valid reference to take the mmap_lock during scenarios described above. [1]
from current->mm. This guarantees we have a valid reference to take the mmap_lock during scenarios described above. [1] https://syzkaller.appspot.com/bug?extid=f7dc54e5be28950ac459 [2] https://syzkaller.appspot.com/bug?extid=a75ebe0452711c9e56d9 References: - https://git.kernel.org/stable/c/81203ab7a6ef843a2b904a0a494f28c457d44d27 - https://git.kernel.org/stable/c/b2a97babb0a510f8921891f9e70c5a5ef33cadac - https://git.kernel.org/stable/c/1da52815d5f1b654c89044db0cdc6adce43da1f1
CVE ID: CVE-2022-49948 State: PUBLISHED Published: 2025-06-18T11:00:12.364Z Last Updated: 2025-06-18T11:00:12.364Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vt: Clear selection before changing the font When changing the console font with ioctl(KDFONTOP) the new font size can be bigger than the previous font. A previous selection may thus now be outside of the new screen size and thus trigger out-of-bounds accesses to graphics memory if the selection is removed in vc_do_resize(). Prevent such out-of-memory accesses by dropping the selection before the various con_font_set() console handlers are called. References: - https:/
accesses by dropping the selection before the various con_font_set() console handlers are called. References: - https://git.kernel.org/stable/c/c555cf04684fde39b5b0dd9fd80730030ee10c4a - https://git.kernel.org/stable/c/e9ba4611ddf676194385506222cce7b0844e708e - https://git.kernel.org/stable/c/f74b4a41c5d7c9522469917e3072e55d435efd9e - https://git.kernel.org/stable/c/1cf1930369c9dc428d827b60260c53271bff3285 - https://git.kernel.org/stable/c/989201bb8c00b222235aff04e6200230d29dc7bb - https://git.kernel.org/stable/c/2535431ae967ad17585513649625fea7db28d4db - https://git.kernel.org/stable/c/c904fe03c4bd1f356a58797d39e2a5d0ca15cefc - https://git.kernel.org/stable/c/566f9c9f89337792070b5a6062dff4
l.org/stable/c/c904fe03c4bd1f356a58797d39e2a5d0ca15cefc - https://git.kernel.org/stable/c/566f9c9f89337792070b5a6062dff448b3e7977f
CVE ID: CVE-2022-49949 State: PUBLISHED Published: 2025-06-18T11:00:13.277Z Last Updated: 2025-06-18T11:00:13.277Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Fix memory leak in firmware upload In the case of firmware-upload, an instance of struct fw_upload is allocated in firmware_upload_register(). This data needs to be freed in fw_dev_release(). Create a new fw_upload_free() function in sysfs_upload.c to handle the firmware-upload specific memory frees and incorporate the missing kfree call for the fw_upload structure. References: - https://git.kernel.org/stable/c/baf92485d111be828e1ab84a995515b604b938e5
all for the fw_upload structure. References: - https://git.kernel.org/stable/c/baf92485d111be828e1ab84a995515b604b938e5 - https://git.kernel.org/stable/c/789bba82f63c3e81dce426ba457fc7905b30ac6e
CVE ID: CVE-2022-49950 State: PUBLISHED Published: 2025-06-18T11:00:13.985Z Last Updated: 2025-06-18T11:00:13.985Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix memory corruption on open The probe session-duplication overflow check incremented the session count also when there were no more available sessions so that memory beyond the fixed-size slab-allocated session array could be corrupted in fastrpc_session_alloc() on open(). References: - https://git.kernel.org/stable/c/f8632b8bb53ebc005d8f24a68a0c1f9678c0e908 - https://git.kernel.org/stable/c/5cf2a57c7a01a0d7bdecf875a63682f542891b1b - https://git.kernel
5d8f24a68a0c1f9678c0e908 - https://git.kernel.org/stable/c/5cf2a57c7a01a0d7bdecf875a63682f542891b1b - https://git.kernel.org/stable/c/cf20c3533efc89578ace94fa20a9e63446223c72 - https://git.kernel.org/stable/c/e0578e603065f120a8759b75e0d6c216c7078a39 - https://git.kernel.org/stable/c/d245f43aab2b61195d8ebb64cef7b5a08c590ab4
CVE ID: CVE-2022-49951 State: PUBLISHED Published: 2025-06-18T11:00:14.694Z Last Updated: 2025-06-18T11:00:14.694Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Fix use-after-free during unregister In the following code within firmware_upload_unregister(), the call to device_unregister() could result in the dev_release function freeing the fw_upload_priv structure before it is dereferenced for the call to module_put(). This bug was found by the kernel test robot using CONFIG_KASAN while running the firmware selftests. device_unregister(&fw_sysfs->dev); module_put(fw_upload_priv->module); The problem is fixed b
ng the firmware selftests. device_unregister(&fw_sysfs->dev); module_put(fw_upload_priv->module); The problem is fixed by copying fw_upload_priv->module to a local variable for use when calling device_unregister(). References: - https://git.kernel.org/stable/c/d380d40930a674c520a5b55f3be1eb17dc634ebc - https://git.kernel.org/stable/c/8b40c38e37492b5bdf8e95b46b5cca9517a9957a
CVE ID: CVE-2022-49952 State: PUBLISHED Published: 2025-06-18T11:00:15.434Z Last Updated: 2025-06-18T11:00:15.434Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix memory corruption on probe Add the missing sanity check on the probed-session count to avoid corrupting memory beyond the fixed-size slab-allocated session array when there are more than FASTRPC_MAX_SESSIONS sessions defined in the devicetree. References: - https://git.kernel.org/stable/c/ec186b9f4aa2e6444d5308a6cc268aada7007639 - https://git.kernel.org/stable/c/c99bc901d5eb9fbdd7bd39f625e170ce97390336 - https://git.kernel.org/stable/c/0e33b0f322fecd
ttps://git.kernel.org/stable/c/c99bc901d5eb9fbdd7bd39f625e170ce97390336 - https://git.kernel.org/stable/c/0e33b0f322fecd7a92d9dc186535cdf97940a856 - https://git.kernel.org/stable/c/c0425c2facd9166fa083f90c9f3187ace0c7837a - https://git.kernel.org/stable/c/9baa1415d9abdd1e08362ea2dcfadfacee8690b5
CVE ID: CVE-2022-49953 State: PUBLISHED Published: 2025-06-18T11:00:16.249Z Last Updated: 2025-06-18T11:00:16.249Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: light: cm3605: Fix an error handling path in cm3605_probe() The commit in Fixes also introduced a new error handling path which should goto the existing error handling path. Otherwise some resources leak. References: - https://git.kernel.org/stable/c/3f7f49d8135cfe137c81316af64678f4dca1b82b - https://git.kernel.org/stable/c/160905549e663019e26395ed9d66c24ee2cf5187
CVE ID: CVE-2022-49954 State: PUBLISHED Published: 2025-06-18T11:00:16.928Z Last Updated: 2025-06-18T11:00:16.928Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag syzbot is reporting hung task at __input_unregister_device() [1], for iforce_close() waiting at wait_event_interruptible() with dev->mutex held is blocking input_disconnect_device() from __input_unregister_device(). It seems that the cause is simply that commit c2b27ef672992a20 ("Input: iforce - wait for command completion when closing the device") forgot to call wake_up() after clear_bit(). Fix this probl
force - wait for command completion when closing the device") forgot to call wake_up() after clear_bit(). Fix this problem by introducing a helper that calls clear_bit() followed by wake_up_all(). References: - https://git.kernel.org/stable/c/d186c65599bff0222da37b9215784ddfe39f9e1b - https://git.kernel.org/stable/c/b271090eea3899399e2adcf79c9c95367d472b03 - https://git.kernel.org/stable/c/df1b53bc799d58f79701c465505a206c72ad4ab8 - https://git.kernel.org/stable/c/b533b9d3a0d1327cbb31c201dc8dbbf98c8bfe3c - https://git.kernel.org/stable/c/98e01215708b6d416345465c09dce2bd4868c67a
CVE ID: CVE-2022-49955 State: PUBLISHED Published: 2025-06-18T11:00:17.617Z Last Updated: 2025-06-18T11:00:17.617Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/rtas: Fix RTAS MSR[HV] handling for Cell The semi-recent changes to MSR handling when entering RTAS (firmware) cause crashes on IBM Cell machines. An example trace: kernel tried to execute user page (2fff01a8) - exploit attempt? (uid: 0) BUG: Unable to handle kernel instruction fetch Faulting instruction address: 0x2fff01a8 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 NUMA Cell Modules linked in: CPU: 0 PID: 0 Comm: swap
of bad area, sig: 11 [#1] BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 NUMA Cell Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.0.0-rc2-00433-gede0a8d3307a #207 NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 0000000000000000 REGS: c0000000015236b0 TRAP: 0400 Tainted: G W (6.0.0-rc2-00433-gede0a8d3307a) MSR: 0000000008001002 <ME,RI> CR: 00000000 XER: 20000000 ... NIP 0x2fff01a8 LR 0x32608 Call Trace: 0xc00000000143c5f8 (unreliable) .rtas_call+0x224/0x320 .rtas_get_boot_time+0x70/0x150 .read_persistent_clock64+0x114/0x140 .read_persistent_wall_and_boot_offset+0x24/0x80 .timekeeping_init+0x40/0x29c .start_kernel+0x674/0x8f0 start_here_common+0x1c/0x50 Unlike PAPR platforms where R
24/0x80 .timekeeping_init+0x40/0x29c .start_kernel+0x674/0x8f0 start_here_common+0x1c/0x50 Unlike PAPR platforms where RTAS is only used in guests, on the IBM Cell machines Linux runs with MSR[HV] set but also uses RTAS, provided by SLOF. Fix it by copying the MSR[HV] bit from the MSR value we've just read using mfmsr into the value used for RTAS. It seems like we could also fix it using an #ifdef CELL to set MSR[HV], but that doesn't work because it's possible to build a single kernel image that runs on both Cell native and pseries. References: - https://git.kernel.org/stable/c/8b08d4f97233d8e58fff2fd9d5f86397a49733c5 - https://git.kernel.org/stable/c/91926d8b7e71aaf5f84f0cf208fc5a8b7a76105
ble/c/8b08d4f97233d8e58fff2fd9d5f86397a49733c5 - https://git.kernel.org/stable/c/91926d8b7e71aaf5f84f0cf208fc5a8b7a761050
CVE ID: CVE-2022-49956 State: PUBLISHED Published: 2025-06-18T11:00:18.341Z Last Updated: 2025-06-18T11:00:18.341Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix use after free bugs _Read/Write_MACREG callbacks are NULL so the read/write_macreg_hdl() functions don't do anything except free the "pcmd" pointer. It results in a use after free. Delete them. References: - https://git.kernel.org/stable/c/7dce6b0ee7d78667d6c831ced957a08769973063 - https://git.kernel.org/stable/c/376e15487fec837301d888068a3fcc82efb6171a - https://git.kernel.org/stable/c/9fd6170c5e2d0ccd027abe26f6f5ffc528e1bb27 - https://git.kernel