Page 24 of 4561 results (0.012 seconds)

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

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: 0%CPEs: 8EXPL: 0

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: 0%CPEs: 8EXPL: 0

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: 0%CPEs: 6EXPL: 0

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 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks. • https://git.kernel.org/stable/c/019c4fbaa790e2b3f11dab0c8b7d9896d77db3e5 https://git.kernel.org/stable/c/6b37f0dc0638d13a006f2f24d2f6ca61e83bc714 https://git.kernel.org/stable/c/dbdcfb9f6748218a149f62468d6297ce3f014e9c https://git.kernel.org/stable/c/cff35329070b96b4484d23f9f48a5ca2c947e750 https://git.kernel.org/stable/c/6778434706940b8fad7ef35f410d2b9929f256d2 https://git.kernel.org/stable/c/27eb2d7a1b9987b6d0429b7716b1ff3b82c4ffc9 https://git.kernel.org/stable/c/908b2da426fe9c3ce74cf541ba40e7a4251db191 https://git.kernel.org/stable/c/f41547546db9af99da2c34e3368664d7a •