Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-49499 State: PUBLISHED Published: 2025-02-26T02:13:33.569Z Last Updated: 2025-10-01T19:46:43.046Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix null pointer dereferences without iommu Check if 'aspace' is set before using it as it will stay null without IOMMU, such as on msm8974. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f09937e80f9bc792965476c9a528f26c8fdc9179 - https://git.kernel.org/stable/c/36a1d1bda77e1851bddfa9cf4e8ada94476dbaff
CVE ID: CVE-2022-49500 State: PUBLISHED Published: 2025-02-26T02:13:34.223Z Last Updated: 2025-05-04T08:39:16.013Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wl1251: dynamically allocate memory used for DMA With introduction of vmap'ed stacks, stack parameters can no longer be used for DMA and now leads to kernel panic. It happens at several places for the wl1251 (e.g. when accessed through SDIO) making it unuseable on e.g. the OpenPandora. We solve this by allocating temporary buffers or use wl1251_read32(). Tested on v5.18-rc5 with OpenPandora. References: - https://git.kernel.org/stable/c/da03bbfbf5acd1ab0b074617e865ad1e
(). Tested on v5.18-rc5 with OpenPandora. References: - https://git.kernel.org/stable/c/da03bbfbf5acd1ab0b074617e865ad1e8a5779ef - https://git.kernel.org/stable/c/454744754cbf2c21b3fc7344e46e10bee2768094
CVE ID: CVE-2022-49501 State: PUBLISHED Published: 2025-02-26T02:13:34.885Z Last Updated: 2025-07-17T16:56:35.614Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usbnet: Run unregister_netdev() before unbind() again Commit 2c9d6c2b871d ("usbnet: run unbind() before unregister_netdev()") sought to fix a use-after-free on disconnect of USB Ethernet adapters. It turns out that a different fix is necessary to address the issue: https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/ So the commit was not necessary. The commit made binding and unbinding of USB Ethernet asymmetrical: Be
lukas@wunner.de/ So the commit was not necessary. The commit made binding and unbinding of USB Ethernet asymmetrical: Before, usbnet_probe() first invoked the ->bind() callback and then register_netdev(). usbnet_disconnect() mirrored that by first invoking unregister_netdev() and then ->unbind(). Since the commit, the order in usbnet_disconnect() is reversed and no longer mirrors usbnet_probe(). One consequence is that a PHY disconnected (and stopped) in ->unbind() is afterwards stopped once more by unregister_netdev() as it closes the netdev before unregistering. That necessitates a contortion in ->stop() because the PHY may only be stopped if it hasn't already been disconnected. Reverting
ssitates a contortion in ->stop() because the PHY may only be stopped if it hasn't already been disconnected. Reverting the commit allows making the call to phy_stop() unconditional in ->stop(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/6d5deb242874d924beccf7eb3cef04c1c3b0da79 - https://git.kernel.org/stable/c/fbda837107f9bd4ec658d2aa88c6856dba606f06 - https://git.kernel.org/stable/c/969a1b3ea3cb7d58a16fe12fd1b04bfc0ea40509 - https://git.kernel.org/stable/c/d1408f6b4dd78fb1b9e26bcf64477984e5f85409
CVE ID: CVE-2022-49502 State: PUBLISHED Published: 2025-02-26T02:13:35.528Z Last Updated: 2025-10-01T19:46:42.899Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: rga: fix possible memory leak in rga_probe rga->m2m_dev needs to be freed when rga_probe fails. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8ddc89437ccefa18279918c19a61fd81527f40b9 - https://git.kernel.org/stable/c/eeb4819e94aa69767b9e5591e70c63e8b7c5786a - https://git.kernel.org/stable/c/b7bbca4d08471bc8404a946bab1aa017dd05199b - https://git.kernel.org/stable/c/1cdc768468c25d6b10ab83ec1efd4a8554532d69 - https
bca4d08471bc8404a946bab1aa017dd05199b - https://git.kernel.org/stable/c/1cdc768468c25d6b10ab83ec1efd4a8554532d69 - https://git.kernel.org/stable/c/a71eb6025305192e646040cd76ccacb5bd48a1b5
CVE ID: CVE-2022-49503 State: PUBLISHED Published: 2025-02-26T02:13:36.149Z Last Updated: 2025-05-04T08:39:20.063Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' References: - https://git.kernel.org/stable/c/0bcb528402cd5e1a6e1833e956fd58a12d509e8e - https://git.kernel.org/stable/c/a048e0c3caa852397b7b50d4c82a0
el.org/stable/c/0bcb528402cd5e1a6e1833e956fd58a12d509e8e - https://git.kernel.org/stable/c/a048e0c3caa852397b7b50d4c82a0415c05f7ac3 - https://git.kernel.org/stable/c/4bdcf32c965c27f55ccc4ee71c1927131115b0bb - https://git.kernel.org/stable/c/2326d398ccd41ba6d93b8346532dfa432ab00fee - https://git.kernel.org/stable/c/461e4c1f199076275f16bf6f3d3e42c6b6c79f33 - https://git.kernel.org/stable/c/7f6defe0fabc79f29603c6fa3c80e4fe0456a3e9 - https://git.kernel.org/stable/c/eda518db7db16c360bc84379d90675650daa3048 - https://git.kernel.org/stable/c/3dad3fed5672828c7fb0465cb66a3d9a70952fa6 - https://git.kernel.org/stable/c/2dc509305cf956381532792cb8dceef2b1504765
CVE ID: CVE-2022-49504 State: PUBLISHED Published: 2025-02-26T02:13:36.829Z Last Updated: 2025-05-04T08:39:21.409Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Inhibit aborts if external loopback plug is inserted After running a short external loopback test, when the external loopback is removed and a normal cable inserted that is directly connected to a target device, the system oops in the llpfc_set_rrq_active() routine. When the loopback was inserted an FLOGI was transmit. As we're looped back, we receive the FLOGI request. The FLOGI is ABTS'd as we recognize the same wppn thus understand it's a loopback. Howev
, we receive the FLOGI request. The FLOGI is ABTS'd as we recognize the same wppn thus understand it's a loopback. However, as the ABTS sends address information the port is not set to (fffffe), the ABTS is dropped on the wire. A short 1 frame loopback test is run and completes before the ABTS times out. The looback is unplugged and the new cable plugged in, and the an FLOGI to the new device occurs and completes. Due to a mixup in ref counting the completion of the new FLOGI releases the fabric ndlp. Then the original ABTS completes and references the released ndlp generating the oops. Correct by no-op'ing the ABTS when in loopback mode (it will be dropped anyway). Added a flag to track the
ing the oops. Correct by no-op'ing the ABTS when in loopback mode (it will be dropped anyway). Added a flag to track the mode to recognize when it should be no-op'd. References: - https://git.kernel.org/stable/c/a1516930cb605caee3bc7b4f3b7994b88c0b8505 - https://git.kernel.org/stable/c/ead76d4c09b89f4c8d632648026a476a5a34fde8
CVE ID: CVE-2022-49505 State: PUBLISHED Published: 2025-02-26T02:13:37.496Z Last Updated: 2025-05-04T12:44:52.412Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: NFC: NULL out the dev->rfkill to prevent UAF Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device") assumes the device_is_registered() in function nfc_dev_up() will help to check when the rfkill is unregistered. However, this check only take effect when device_del(&dev->dev) is done in nfc_unregister_device(). Hence, the rfkill object is still possible be dereferenced. The crash trace in latest kernel (5.18-rc2): [ 68.760105] =======================
ect is still possible be dereferenced. The crash trace in latest kernel (5.18-rc2): [ 68.760105] ================================================================== [ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750 [ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313 [ 68.760756] [ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4 [ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 68.760756] Call Trace: [ 68.760756] <TASK> [ 68.760756] dump_stack_lvl+0x57/0x7d [ 68.760756] print_report.cold+0x5e/0x5db [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] kasa
ck_lvl+0x57/0x7d [ 68.760756] print_report.cold+0x5e/0x5db [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] kasan_report+0xbe/0x1c0 [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] __lock_acquire+0x3ec1/0x6750 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? register_lock_class+0x18d0/0x18d0 [ 68.760756] lock_acquire+0x1ac/0x4f0 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0 [ 68.760756] ? nla_get_range_signed+0x540/0x540 [ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50 [ 68.760756] _raw_spin_lock_irqsave+0x39/0x50 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.76
spin_lock_irqsave+0x4e/0x50 [ 68.760756] _raw_spin_lock_irqsave+0x39/0x50 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] rfkill_blocked+0xe/0x60 [ 68.760756] nfc_dev_up+0x84/0x260 [ 68.760756] nfc_genl_dev_up+0x90/0xe0 [ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0 [ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230 [ 68.760756] ? security_capable+0x51/0x90 [ 68.760756] genl_rcv_msg+0x280/0x500 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? lock_acquire+0x1ac/0x4f0 [ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] netlink_rcv_skb+0x11b/0x340 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? n
on_prepare+0x410/0x410 [ 68.760756] netlink_rcv_skb+0x11b/0x340 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? netlink_ack+0x9c0/0x9c0 [ 68.760756] ? netlink_deliver_tap+0x136/0xb00 [ 68.760756] genl_rcv+0x1f/0x30 [ 68.760756] netlink_unicast+0x430/0x710 [ 68.760756] ? memset+0x20/0x40 [ 68.760756] ? netlink_attachskb+0x740/0x740 [ 68.760756] ? __build_skb_around+0x1f4/0x2a0 [ 68.760756] netlink_sendmsg+0x75d/0xc00 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] sock_sendmsg+0xdf/0x110 [ 68.760756] __sys_sendto+0x19e/0x270 [ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0 [ 68.760756] ? fd_install+0x178/0x4c0 [ 68.760756] ? fd_install+
e/0x270 [ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0 [ 68.760756] ? fd_install+0x178/0x4c0 [ 68.760756] ? fd_install+0x195/0x4c0 [ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0 [ 68.760756] __x64_sys_sendto+0xd8/0x1b0 [ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130 [ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50 [ 68.760756] do_syscall_64+0x3b/0x90 [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 68.760756] RIP: 0033:0x7f67fb50e6b3 ... [ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3 [ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003 [ 6
000000000000000 RCX: 00007f67fb50e6b3 [ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003 [ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c [ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e [ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003 [ 68.760756] </TASK> [ 68.760756] [ 68.760756] Allocated by task 279: [ 68.760756] kasan_save_stack+0x1e/0x40 [ ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/a8e03bcad52dc9afabf650fdbad84f739cec9efa - https://git.kernel.org/stable/c/f81270125b50532624400063281e6611ecd61ddf - htt
8e03bcad52dc9afabf650fdbad84f739cec9efa - https://git.kernel.org/stable/c/f81270125b50532624400063281e6611ecd61ddf - https://git.kernel.org/stable/c/6abfaca8711803d0d7cc8c0fac1070a88509d463 - https://git.kernel.org/stable/c/fbf9c4c714d3cdeb98b6a18e4d057f931cad1d81 - https://git.kernel.org/stable/c/2a1b5110c95e4d49c8c3906270dfcde680a5a7be - https://git.kernel.org/stable/c/1632be63862f183cd5cf1cc094e698e6ec005dfd - https://git.kernel.org/stable/c/4a68938f43b7c2663e4c90bb9bbe29ac8b9a42a0 - https://git.kernel.org/stable/c/4f5d71930f41be78557f9714393179025baacd65 - https://git.kernel.org/stable/c/1b0e81416a24d6e9b8c2341e22e8bf48f8b8bfc9
CVE ID: CVE-2022-49506 State: PUBLISHED Published: 2025-02-26T02:13:38.168Z Last Updated: 2025-05-04T08:39:24.277Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Add vblank register/unregister callback functions We encountered a kernel panic issue that callback data will be NULL when it's using in ovl irq handler. There is a timing issue between mtk_disp_ovl_irq_handler() and mtk_ovl_disable_vblank(). To resolve this issue, we use the flow to register/unregister vblank cb: - Register callback function and callback data when crtc creates. - Unregister callback function and callback data when crtc destroies. With th
ction and callback data when crtc creates. - Unregister callback function and callback data when crtc destroies. With this solution, we can assure callback data will not be NULL when vblank is disable. References: - https://git.kernel.org/stable/c/8a2dbdeccef6de47565638abdf3c25f41cdffc37 - https://git.kernel.org/stable/c/8a265d9838bc3c63579002d55c2b2c655c4f8f26 - https://git.kernel.org/stable/c/3a4027b5971fe2a94e32754f007d9d3c12c68ad1 - https://git.kernel.org/stable/c/b74d921b900b6ce38c6247c0a1c86be9f3746493
CVE ID: CVE-2022-49507 State: PUBLISHED Published: 2025-02-26T02:13:38.821Z Last Updated: 2025-10-01T19:46:42.759Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: regulator: da9121: Fix uninit-value in da9121_assign_chip_model() KASAN report slab-out-of-bounds in __regmap_init as follows: BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841 Read of size 1 at addr ffff88803678cdf1 by task xrun/9137 CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88 p
40FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88 print_report.cold+0xcd/0x69b mm/kasan/report.c:313 kasan_report+0x8e/0xc0 mm/kasan/report.c:491 __regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841 __devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266 __devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394 da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039 i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563 This happend when da9121 device is probe by da9121_i2c_id, but with invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later da9121_assign_chip_mod
be by da9121_i2c_id, but with invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later da9121_assign_chip_model() will access 'regmap' without init it. Fix it by return -EINVAL from da9121_assign_chip_model() if 'chip->subvariant_id' is invalid. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/be96baa0c79588084e0d7a4fa21c574cec9a57f4 - https://git.kernel.org/stable/c/7da64c7c82c9b29b628a62c88a8c2fb06990563d - https://git.kernel.org/stable/c/60f21eda69f1b5727a97d2077da766eb27fcc21f - https://git.kernel.org/stable/c/bab76514aca36bc513224525d5598da676938218
CVE ID: CVE-2022-49508 State: PUBLISHED Published: 2025-02-26T02:13:39.472Z Last Updated: 2025-10-01T19:46:42.617Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: elan: Fix potential double free in elan_input_configured 'input' is a managed resource allocated with devm_input_allocate_device(), so there is no need to call input_free_device() explicitly or there will be a double free. According to the doc of devm_input_allocate_device(): * Managed input devices do not need to be explicitly unregistered or * freed as it will be done automatically when owner device unbinds from * its driver (or binding fails). Additional Analys
freed as it will be done automatically when owner device unbinds from * its driver (or binding fails). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c92ec22a991778a096342cf1a917ae36c5c86a90 - https://git.kernel.org/stable/c/f1d4f19a796551edc6679a681ea1756b8c578c08 - https://git.kernel.org/stable/c/6d0726725c7c560495f5ff364862a2cefea542e3 - https://git.kernel.org/stable/c/24f9dfdaece9bd75bb8dbfdba83eddeefdf7dc47 - https://git.kernel.org/stable/c/5291451851feeb66fd4bf0826710f482f3b1ab38 - https://git.kernel.org/stable/c/8bb1716507ebf12d50bbf181764481de3b6bc7fd - https://git.kernel.org/stable/c/1af20714fedad238362571620be0bd690ded05b6
CVE ID: CVE-2022-49509 State: PUBLISHED Published: 2025-02-26T02:13:40.134Z Last Updated: 2025-05-04T08:39:28.147Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: i2c: max9286: fix kernel oops when removing module When removing the max9286 module we get a kernel oops: Unable to handle kernel paging request at virtual address 000000aa00000094 Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000 [000000aa00000094]
ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000 [000000aa00000094] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: fsl_jr_uio caam_jr rng_core libdes caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine max9271 authenc crct10dif_ce mxc_jpeg_encdec CPU: 2 PID: 713 Comm: rmmod Tainted: G C 5.15.5-00057-gaebcd29c8ed7-dirty #5 Hardware name: Freescale i.MX8QXP MEK (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : i2c_mux_del_adapters+0x24/0xf0 lr : max9286_remove+0x28/0xd0 [max9286] sp : ffff800013a9bbf0 x29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0
24/0xf0 lr : max9286_remove+0x28/0xd0 [max9286] sp : ffff800013a9bbf0 x29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000801a5b970 x22: ffff0008048b0890 x21: ffff800009297000 x20: ffff0008048b0f70 x19: 000000aa00000064 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000014 x13: 0000000000000000 x12: ffff000802da49e8 x11: ffff000802051918 x10: ffff000802da4920 x9 : ffff000800030098 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffffffffffffffff x1 : ffff00080
fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffffffffffffffff x1 : ffff00080b6da940 x0 : 0000000000000000 Call trace: i2c_mux_del_adapters+0x24/0xf0 max9286_remove+0x28/0xd0 [max9286] i2c_device_remove+0x40/0x110 __device_release_driver+0x188/0x234 driver_detach+0xc4/0x150 bus_remove_driver+0x60/0xe0 driver_unregister+0x34/0x64 i2c_del_driver+0x58/0xa0 max9286_i2c_driver_exit+0x1c/0x490 [max9286] __arm64_sys_delete_module+0x194/0x260 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xd4/0xfc do_el0_svc+0x2c/0x94 el0_svc+0x28/0x80 el0t_64_sync_handler+0xa8/0x130 el0t_64_sync+0x1a0/0x1a4 The Oops happens because the I2C client data does not point
x80 el0t_64_sync_handler+0xa8/0x130 el0t_64_sync+0x1a0/0x1a4 The Oops happens because the I2C client data does not point to max9286_priv anymore but to v4l2_subdev. The change happened in max9286_init() which calls v4l2_i2c_subdev_init() later on... Besides fixing the max9286_remove() function, remove the call to i2c_set_clientdata() in max9286_probe(), to avoid confusion, and make the necessary changes to max9286_init() so that it doesn't have to use i2c_get_clientdata() in order to fetch the pointer to priv. References: - https://git.kernel.org/stable/c/a4ec75df70575cdf33d9638c7844e729bfe6ce24 - https://git.kernel.org/stable/c/579c77595dbbdfe4f2edf335899f86ac51eca4e9 - https://git.kernel.o
d9638c7844e729bfe6ce24 - https://git.kernel.org/stable/c/579c77595dbbdfe4f2edf335899f86ac51eca4e9 - https://git.kernel.org/stable/c/9dd783274c89c21a038d967b52a858a297e767f8 - https://git.kernel.org/stable/c/365ab7ebc24eebb42b9e020aeb440d51af8960cd
CVE ID: CVE-2022-49510 State: PUBLISHED Published: 2025-02-26T02:13:40.777Z Last Updated: 2025-10-01T19:46:42.480Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/omap: fix NULL but dereferenced coccicheck error Fix the following coccicheck warning: ./drivers/gpu/drm/omapdrm/omap_overlay.c:89:22-25: ERROR: r_ovl is NULL but dereferenced. Here should be ovl->idx rather than r_ovl->idx. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d2507be660310bb9bcca918f81f49b8bba07e462 - https://git.kernel.org/stable/c/08d9a75eab594ca508a440db7c73064498d26687 - https://git.kernel.org/stable
49b8bba07e462 - https://git.kernel.org/stable/c/08d9a75eab594ca508a440db7c73064498d26687 - https://git.kernel.org/stable/c/8f2a3970c969d0d8d7289a4c65edcedafc16fd92
CVE ID: CVE-2022-49511 State: PUBLISHED Published: 2025-02-26T02:13:41.433Z Last Updated: 2025-05-04T08:39:30.414Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fbdev: defio: fix the pagelist corruption Easily hit the below list corruption: == list_add corruption. prev->next should be next (ffffffffc0ceb090), but was ffffec604507edc8. (prev=ffffec604507edc8). WARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26 __list_add_valid+0x53/0x80 CPU: 65 PID: 3959 Comm: fbdev Tainted: G U RIP: 0010:__list_add_valid+0x53/0x80 Call Trace: <TASK> fb_deferred_io_mkwrite+0xea/0x150 do_page_mkwrite+0x57/0xc0 do_wp_page+0x278/0x2f0 __handle_mm_f
0x80 Call Trace: <TASK> fb_deferred_io_mkwrite+0xea/0x150 do_page_mkwrite+0x57/0xc0 do_wp_page+0x278/0x2f0 __handle_mm_fault+0xdc2/0x1590 handle_mm_fault+0xdd/0x2c0 do_user_addr_fault+0x1d3/0x650 exc_page_fault+0x77/0x180 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x7fd98fc8fad1 == Figure out the race happens when one process is adding &page->lru into the pagelist tail in fb_deferred_io_mkwrite(), another process is re-initializing the same &page->lru in fb_deferred_io_fault(), which is not protected by the lock. This fix is to init all the page lists one time during initialization, it not only fixes the list corruption, but also avoids INIT_LIST_HEAD() redundantly.
sts one time during initialization, it not only fixes the list corruption, but also avoids INIT_LIST_HEAD() redundantly. V2: change "int i" to "unsigned int i" (Geert Uytterhoeven) References: - https://git.kernel.org/stable/c/e79b2b2aadeffe1db54a6b569b9b621575c3eb07 - https://git.kernel.org/stable/c/6a9ae2fe887042f76fd3d334349e64e8ab3c55a2 - https://git.kernel.org/stable/c/856082f021a28221db2c32bd0531614a8382be67