CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2022-48975 – gpiolib: fix memory leak in gpiochip_setup_dev()
https://notcve.org/view.php?id=CVE-2022-48975
In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix memory leak in gpiochip_setup_dev() Here is a backtrace report about memory leak detected in gpiochip_setup_dev(): unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key gcdev_register() & gcdev_unregister() would call device_add() & device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device. However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del(). Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path. Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree(). While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable. • https://git.kernel.org/stable/c/159f3cd92f17c61a4e2a47456de5865b114ef88e https://git.kernel.org/stable/c/6daaa84b621485fe28c401be18debf92ae8ef04a https://git.kernel.org/stable/c/371363716398ed718e389bea8c5e9843a79dde4e https://git.kernel.org/stable/c/ec851b23084b3a0af8bf0f5e51d33a8d678bdc49 •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2022-48973 – gpio: amd8111: Fix PCI device reference count leak
https://notcve.org/view.php?id=CVE-2022-48973
In the Linux kernel, the following vulnerability has been resolved: gpio: amd8111: Fix PCI device reference count leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the 'Device not found' branch. For the normal path, add pci_dev_put() in amd_gpio_exit(). • https://git.kernel.org/stable/c/f942a7de047d8c599cc1a9a26293c8c7400450ea https://git.kernel.org/stable/c/4749c5cc147c9860b96db1e71cc36d1de1bd3f59 https://git.kernel.org/stable/c/71d591ef873f9ebb86cd8d053b3caee785b2de6a https://git.kernel.org/stable/c/b2bc053ebbba57a06fa655db5ea796de2edce445 https://git.kernel.org/stable/c/48bd5d3801f6b67cc144449d434abbd5043a6d37 https://git.kernel.org/stable/c/5ee6413d3dd972930af787b2c0c7aaeb379fa521 https://git.kernel.org/stable/c/4271515f189bd5fe2ec86b4089dab7cb804625d2 https://git.kernel.org/stable/c/e364ce04d8f840478b09eee57b614de7c •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2022-48972 – mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()
https://notcve.org/view.php?id=CVE-2022-48972
In the Linux kernel, the following vulnerability has been resolved: mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add() Kernel fault injection test reports null-ptr-deref as follows: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114 Call Trace: <TASK> raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944 unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982 unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879 register_netdevice+0x9a8/0xb90 net/core/dev.c:10083 ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659 ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229 mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316 ieee802154_if_add() allocates wpan_dev as netdev's private data, but not init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage the list when device register/unregister, and may lead to null-ptr-deref. Use INIT_LIST_HEAD() on it to initialize it correctly. • https://git.kernel.org/stable/c/fcf39e6e88e9492f6688ec8ba4e1be622b904232 https://git.kernel.org/stable/c/7410f4d1221bb182510b7778ab6eefa8b9b7102d https://git.kernel.org/stable/c/9980a3ea20de40c83817877106c909cb032692d2 https://git.kernel.org/stable/c/f00c84fb1635c27ba24ec5df65d5bd7d7dc00008 https://git.kernel.org/stable/c/1831d4540406708e48239cf38fd9c3b7ea98e08f https://git.kernel.org/stable/c/42c319635c0cf7eb36eccac6cda76532f47b61a3 https://git.kernel.org/stable/c/a110287ef4a423980309490df632e1c1e73b3dc9 https://git.kernel.org/stable/c/623918f40fa68e3bb21312a3fafb90f49 •
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2022-48971 – Bluetooth: Fix not cleanup led when bt_init fails
https://notcve.org/view.php?id=CVE-2022-48971
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix not cleanup led when bt_init fails bt_init() calls bt_leds_init() to register led, but if it fails later, bt_leds_cleanup() is not called to unregister it. This can cause panic if the argument "bluetooth-power" in text is freed and then another led_trigger_register() tries to access it: BUG: unable to handle page fault for address: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30 Call Trace: <TASK> led_trigger_register+0x10d/0x4f0 led_trigger_register_simple+0x7d/0x100 bt_init+0x39/0xf7 [bluetooth] do_one_initcall+0xd0/0x4e0 • https://git.kernel.org/stable/c/e64c97b53bc6727aa4385535166aaa047281e02d https://git.kernel.org/stable/c/8a66c3a94285552f6a8e45d73b34ebbad11d388b https://git.kernel.org/stable/c/2c6cf0afc3856359e620e96edd952457d258e16c https://git.kernel.org/stable/c/e7b950458156d410509a08c41930b75e72985938 https://git.kernel.org/stable/c/edf7284a98296369dd0891a0457eec37df244873 https://git.kernel.org/stable/c/5ecf7cd6fde5e72c87122084cf00d63e35d8dd9f https://git.kernel.org/stable/c/2f3957c7eb4e07df944169a3e50a4d6790e1c744 •
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2022-48969 – xen-netfront: Fix NULL sring after live migration
https://notcve.org/view.php?id=CVE-2022-48969
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Fix NULL sring after live migration A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]--- xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time • https://git.kernel.org/stable/c/4ec2411980d0fd2995e8dea8a06fe57aa47523cb https://git.kernel.org/stable/c/99859947517e446058ad7243ee81d2f9801fa3dd https://git.kernel.org/stable/c/ed773dd798bf720756d20021b8d8a4a3d7184bda https://git.kernel.org/stable/c/e6860c889f4ad50b6ab696f5ea154295d72cf27a https://git.kernel.org/stable/c/e6e897d4fe2f89c0bd94600a40bedf5e6e75e050 https://git.kernel.org/stable/c/f2dd60fd3fe98bd36a91b0c6e10bfe9d66258f84 https://git.kernel.org/stable/c/d50b7914fae04d840ce36491d22133070b18cca9 •