Page 23 of 4128 results (0.002 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable_offload: fix using __this_cpu_add in preemptible flow_offload_queue_work() can be called in workqueue without bh disabled, like the call trace showed in my act_ct testing, calling NF_FLOW_TABLE_STAT_INC() there would cause a call trace: BUG: using __this_cpu_add() in preemptible [00000000] code: kworker/u4:0/138560 caller is flow_offload_queue_work+0xec/0x1b0 [nf_flow_table] Workqueue: act_ct_workqueue tcf_ct_flow_table_cleanup_work [act_ct] Call Trace: <TASK> dump_stack_lvl+0x33/0x46 check_preemption_disabled+0xc3/0xf0 flow_offload_queue_work+0xec/0x1b0 [nf_flow_table] nf_flow_table_iterate+0x138/0x170 [nf_flow_table] nf_flow_table_free+0x140/0x1a0 [nf_flow_table] tcf_ct_flow_table_cleanup_work+0x2f/0x2b0 [act_ct] process_one_work+0x6a3/0x1030 worker_thread+0x8a/0xdf0 This patch fixes it by using NF_FLOW_TABLE_STAT_INC_ATOMIC() instead in flow_offload_queue_work(). Note that for FLOW_CLS_REPLACE branch in flow_offload_queue_work(), it may not be called in preemptible path, but it's good to use NF_FLOW_TABLE_STAT_INC_ATOMIC() for all cases in flow_offload_queue_work(). • https://git.kernel.org/stable/c/b038177636f83bbf87c2b238706474145dd2cd04 https://git.kernel.org/stable/c/5345d78ae64d5a760c211cd2da995dc71c5b29e4 https://git.kernel.org/stable/c/a220a11fda012fba506b35929672374c2723ae6d https://git.kernel.org/stable/c/a81047154e7ce4eb8769d5d21adcbc9693542a79 •

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: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: fix using __this_cpu_add in preemptible Currently in nf_conntrack_hash_check_insert(), when it fails in nf_ct_ext_valid_pre/post(), NF_CT_STAT_INC() will be called in the preemptible context, a call trace can be triggered: BUG: using __this_cpu_add() in preemptible [00000000] code: conntrack/1636 caller is nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack] Call Trace: <TASK> dump_stack_lvl+0x33/0x46 check_preemption_disabled+0xc3/0xf0 nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack] ctnetlink_create_conntrack+0x3cd/0x4e0 [nf_conntrack_netlink] ctnetlink_new_conntrack+0x1c0/0x450 [nf_conntrack_netlink] nfnetlink_rcv_msg+0x277/0x2f0 [nfnetlink] netlink_rcv_skb+0x50/0x100 nfnetlink_rcv+0x65/0x144 [nfnetlink] netlink_unicast+0x1ae/0x290 netlink_sendmsg+0x257/0x4f0 sock_sendmsg+0x5f/0x70 This patch is to fix it by changing to use NF_CT_STAT_INC_ATOMIC() for nf_ct_ext_valid_pre/post() check in nf_conntrack_hash_check_insert(), as well as nf_ct_ext_valid_post() in __nf_conntrack_confirm(). Note that nf_ct_ext_valid_pre() check in __nf_conntrack_confirm() is safe to use NF_CT_STAT_INC(), as it's under local_bh_disable(). • https://git.kernel.org/stable/c/c56716c69ce1ac320432fb1ea5654196ba24d2f8 https://git.kernel.org/stable/c/d9bf1138a5db419db13bd9fcd3a7178d6bb20f7c https://git.kernel.org/stable/c/9464d0b68f11a9bc768370c3260ec02b3550447b •

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 •