- Nov 20, 2023
-
-
Jian Shen authored
[ Upstream commit 8ffbd166 ] When ptr_ring_init() returns failure in page_pool_init(), free_percpu() is not called to free pool->recycle_stats, which may cause memory leak. Fixes: ad6fa1e1 ("page_pool: Add recycle stats") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Jijie Shao <shaojijie@huawei.com> Reviewed-by:
Yunsheng Lin <linyunsheng@huawei.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Link: https://lore.kernel.org/r/20231030091256.2915394-1-shaojijie@huawei.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ratheesh Kannoth authored
[ Upstream commit 7aeeb2cb ] Error code strings are not getting printed properly due to holes. Print error code as well. Fixes: 51afe902 ("octeontx2-pf: NIX TX overwrites SQ_CTX_HW_S[SQ_INT]") Signed-off-by:
Ratheesh Kannoth <rkannoth@marvell.com> Reviewed-by:
Wojciech Drewek <wojciech.drewek@intel.com> Link: https://lore.kernel.org/r/20231027021953.1819959-2-rkannoth@marvell.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ratheesh Kannoth authored
[ Upstream commit 96b9a68d ] Some of error codes were wrong. Fix the same. Fixes: 51afe902 ("octeontx2-pf: NIX TX overwrites SQ_CTX_HW_S[SQ_INT]") Signed-off-by:
Ratheesh Kannoth <rkannoth@marvell.com> Reviewed-by:
Wojciech Drewek <wojciech.drewek@intel.com> Link: https://lore.kernel.org/r/20231027021953.1819959-1-rkannoth@marvell.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Eric Dumazet authored
[ Upstream commit 1726483b ] I am looking at syzbot reports triggering kernel stack overflows involving a cascade of ipvlan devices. We can save 8 bytes in struct flowi_common. This patch alone will not fix the issue, but is a start. Fixes: 24ba1440 ("route: Add multipath_hash in flowi_common to make user-define hash") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: wenxu <wenxu@ucloud.cn> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20231025141037.3448203-1-edumazet@google.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hou Tao authored
[ Upstream commit fd381ce6 ] When there are concurrent uref release and bpf timer init operations, the following sequence diagram is possible. It will break the guarantee provided by bpf_timer: bpf_timer will still be alive after userspace application releases or unpins the map. It also will lead to kmemleak for old kernel version which doesn't release bpf_timer when map is released. bpf program X: bpf_timer_init() lock timer->lock read timer->timer as NULL read map->usercnt != 0 process Y: close(map_fd) // put last uref bpf_map_put_uref() atomic_dec_and_test(map->usercnt) array_map_free_timers() bpf_timer_cancel_and_free() // just return read timer->timer is NULL t = bpf_map_kmalloc_node() timer->timer = t unlock timer->lock Fix the problem by checking map->usercnt after timer->timer is assigned, so when there are concurrent uref release and bpf timer init, either bpf_timer_cancel_and_free() from uref release reads a no-NULL timer or the newly-added atomic64_read() returns a zero usercnt. Because atomic_dec_and_test(map->usercnt) and READ_ONCE(timer->timer) in bpf_timer_cancel_and_free() are not protected by a lock, so add a memory barrier to guarantee the order between map->usercnt and timer->timer. Also use WRITE_ONCE(timer->timer, x) to match the lockless read of timer->timer in bpf_timer_cancel_and_free(). Reported-by:
Hsin-Wei Hung <hsinweih@uci.edu> Closes: https://lore.kernel.org/bpf/CABcoxUaT2k9hWsS1tNgXyoU3E-=PuOgMn737qK984fbFmfYixQ@mail.gmail.com Fixes: b00628b1 ("bpf: Introduce bpf timers.") Signed-off-by:
Hou Tao <houtao1@huawei.com> Link: https://lore.kernel.org/r/20231030063616.1653024-1-houtao@huaweicloud.com Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Shigeru Yoshida authored
[ Upstream commit 19b3f72a ] syzbot reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline] BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline] genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline] netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd TIPC bearer-related names including link names must be null-terminated strings. If a link name which is not null-terminated is passed through netlink, strstr() and similar functions can cause buffer overrun. This causes the above issue. This patch changes the nla_policy for bearer-related names from NLA_STRING to NLA_NUL_STRING. This resolves the issue by ensuring that only null-terminated strings are accepted as bearer-related names. syzbot reported similar uninit-value issue related to bearer names [2]. The root cause of this issue is that a non-null-terminated bearer name was passed. This patch also resolved this issue. Fixes: 7be57fc6 ("tipc: add link get/dump to new netlink api") Fixes: 0655f6a8 ("tipc: add bearer disable/enable to new netlink api") Reported-and-tested-by:
<syzbot+5138ca807af9d2b42574@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=5138ca807af9d2b42574 [1] Reported-and-tested-by:
<syzbot+9425c47dccbcb4c17d51@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=9425c47dccbcb4c17d51 [2] Signed-off-by:
Shigeru Yoshida <syoshida@redhat.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20231030075540.3784537-1-syoshida@redhat.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dan Carpenter authored
[ Upstream commit 876f8ab5 ] The prp_fill_rct() function can fail. In that situation, it frees the skb and returns NULL. Meanwhile on the success path, it returns the original skb. So it's straight forward to fix bug by using the returned value. Fixes: 451d8123 ("net: prp: add packet handling support") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Acked-by:
Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/r/57af1f28-7f57-4a96-bcd3-b7a0f2340845@moroto.mountain Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Willem de Bruijn authored
[ Upstream commit 7b3ba187 ] LLC reads the mac header with eth_hdr without verifying that the skb has an Ethernet header. Syzbot was able to enter llc_rcv on a tun device. Tun can insert packets without mac len and with user configurable skb->protocol (passing a tun_pi header when not configuring IFF_NO_PI). BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218 __netif_receive_skb_one_core net/core/dev.c:5523 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5782 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002 Add a mac_len test before all three eth_hdr(skb) calls under net/llc. There are further uses in include/net/llc_pdu.h. All these are protected by a test skb->protocol == ETH_P_802_2. Which does not protect against this tun scenario. But the mac_len test added in this patch in llc_fixup_skb will indirectly protect those too. That is called from llc_rcv before any other LLC code. It is tempting to just add a blanket mac_len check in llc_rcv, but not sure whether that could break valid LLC paths that do not assume an Ethernet header. 802.2 LLC may be used on top of non-802.3 protocols in principle. The below referenced commit shows that used to, on top of Token Ring. At least one of the three eth_hdr uses goes back to before the start of git history. But the one that syzbot exercises is introduced in this commit. That commit is old enough (2008), that effectively all stable kernels should receive this. Fixes: f83f1768 ("[LLC]: skb allocation size for responses") Reported-by:
<syzbot+a8c7be6dee0de1b669cc@syzkaller.appspotmail.com> Signed-off-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20231025234251.3796495-1-willemdebruijn.kernel@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Linus Walleij authored
[ Upstream commit b4075ecf ] The IXP4xx watchdog in early "A0" silicon is unreliable and cannot be registered, however for some systems such as the USRobotics USR8200 the watchdog is the only restart option, so implement a "dummy" watchdog that can only support restart in this case. Fixes: 1aea5228 ("watchdog: ixp4xx: Implement restart") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230926-ixp4xx-wdt-restart-v2-1-15cf4639b423@linaro.org Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dan Carpenter authored
[ Upstream commit eb988e46 ] The put_device() calls rmi_release_function() which frees "fn" so the dereference on the next line "fn->num_of_irqs" is a use after free. Move the put_device() to the end to fix this. Fixes: 24d28e4f ("Input: synaptics-rmi4 - convert irq distribution to irq_domain") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/706efd36-7561-42f3-adfa-dd1d0bd4f5a1@moroto.mountain Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Florian Fainelli authored
[ Upstream commit e9bc4411 ] The suspend/resume functions currently utilize clk_disable()/clk_enable() respectively which may be no-ops with certain clock providers such as SCMI. Fix this to use clk_disable_unprepare() and clk_prepare_enable() respectively as we should. Fixes: 3a9f5957 ("pwm: Add Broadcom BCM7038 PWM controller support") Signed-off-by:
Florian Fainelli <florian.fainelli@broadcom.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Uwe Kleine-König authored
[ Upstream commit 2d6812b4 ] Instead of using one allocation per capture channel, use a single one. Also store it in driver data instead of chip data. This has several advantages: - driver data isn't cleared when pwm_put() is called - Reduces memory fragmentation Also register the pwm chip only after the per capture channel data is initialized as the capture callback relies on this initialization and it might be called even before pwmchip_add() returns. It would be still better to have struct sti_pwm_compat_data and the per-channel data struct sti_cpt_ddata in a single memory chunk, but that's not easily possible because the number of capture channels isn't known yet when the driver data struct is allocated. Fixes: e926b12c ("pwm: Clear chip_data in pwm_put()") Reported-by:
George Stark <gnstark@sberdevices.ru> Fixes: c97267ae ("pwm: sti: Add PWM capture callback") Link: https://lore.kernel.org/r/20230705080650.2353391-7-u.kleine-koenig@pengutronix.de Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ben Wolsieffer authored
[ Upstream commit 984a4afd ] Currently, noinc writes are cached as if they were standard incrementing writes, overwriting unrelated register values in the cache. Instead, we want to cache the last value written to the register, as is done in the accelerated noinc handler (regmap_noinc_readwrite). Fixes: cdf6b11d ("regmap: Add regmap_noinc_write API") Signed-off-by:
Ben Wolsieffer <ben.wolsieffer@hefring.com> Link: https://lore.kernel.org/r/20231101142926.2722603-2-ben.wolsieffer@hefring.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Marek Szyprowski authored
[ Upstream commit 94e27fbe ] 'meson' directory contains two separate drivers, so it should be added to Makefile compilation hierarchy unconditionally, because otherwise the meson-ao-cec-g12a won't be compiled if meson-ao-cec is not selected. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Fixes: 4be5e864 ("media: move CEC platform drivers to a separate directory") Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hans Verkuil authored
[ Upstream commit f31b2cb8 ] Instead of returning an error, goto the mutex unlock at the end of the function. Fixes smatch warning: drivers/media/usb/dvb-usb-v2/af9035.c:467 af9035_i2c_master_xfer() warn: inconsistent returns '&d->i2c_mutex'. Locked on : 326,387 Unlocked on: 465,467 Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 7bf744f2 ("media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer") Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Pratyush Yadav authored
[ Upstream commit b2701715 ] The notifier is added to the global notifier list when registered. When the module is removed, the struct csi2rx_priv in which the notifier is embedded, is destroyed. As a result the notifier list has a reference to a notifier that no longer exists. This causes invalid memory accesses when the list is iterated over. Similar for when the probe fails. Unregister and clean up the notifier to avoid this. Fixes: 1fc3b37f ("media: v4l: cadence: Add Cadence MIPI-CSI2 RX driver") Signed-off-by:
Pratyush Yadav <p.yadav@ti.com> Tested-by:
Julien Massot <julien.massot@collabora.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Jai Luthra <j-luthra@ti.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jernej Skrabec authored
[ Upstream commit 36fe515c ] According to H6 user manual, resets should always be de-asserted before clocks are enabled. This is also consistent with vendor driver. Fixes: d5aecd28 ("media: cedrus: Implement runtime PM") Signed-off-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
蒋家盛 authored
[ Upstream commit 1fd6eb12 ] Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Moreover, use kfree() in the later error handling in order to avoid memory leak. Fixes: c2f78f0c ("media: vidtv: psi: add a Network Information Table (NIT)") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
蒋家盛 authored
[ Upstream commit 76a2c5df ] Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Fixes: 7a7899f6 ("media: vidtv: psi: Implement an Event Information Table (EIT)") Fixes: c2f78f0c ("media: vidtv: psi: add a Network Information Table (NIT)") Fixes: f90cf607 ("media: vidtv: add a bridge driver") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Katya Orlova authored
[ Upstream commit 61334819 ] s3c_camif_register_video_node() works with video_device structure stored as a field of camif_vp, so it should not be kfreed. But there is video_device_release() on error path that do it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: babde1c2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface") Signed-off-by:
Katya Orlova <e.orlova@ispras.ru> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Fei Shao authored
[ Upstream commit 0aeccc63 ] The driver uses the upper-bound approach to decide the target JPEG encode quality, but there's a logic bug that if the desired quality is higher than what the driver can support, the driver falls back to using the worst quality. Fix the bug by assuming using the best quality in the beginning, and with trivial refactor to avoid long lines. Fixes: 45f13a57 ("media: platform: Add jpeg enc feature") Signed-off-by:
Fei Shao <fshao@chromium.org> Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ming Qian authored
[ Upstream commit 6496617b ] decoder firmware may notify host some debug message, it can help analyze the state of the firmware in case of error Fixes: 9f599f35 ("media: amphion: add vpu core driver") Signed-off-by:
Ming Qian <ming.qian@nxp.com> Reviewed-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Zheng Wang authored
[ Upstream commit bd5b50b3 ] There may be some a race condition between timer function bttv_irq_timeout and bttv_remove. The timer is setup in probe and there is no timer_delete operation in remove function. When it hit kfree btv, the function might still be invoked, which will cause use after free bug. This bug is found by static analysis, it may be false positive. Fix it by adding del_timer_sync invoking to the remove function. cpu0 cpu1 bttv_probe ->timer_setup ->bttv_set_dma ->mod_timer; bttv_remove ->kfree(btv); ->bttv_irq_timeout ->USE btv Fixes: 162e6376 ("media: pci: Convert timers to use timer_setup()") Signed-off-by:
Zheng Wang <zyytlz.wz@163.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Xiaolei Wang authored
[ Upstream commit 20290fea ] sensor->ctrls.handler is initialized in ov5640_init_controls(), so when the sensor is not connected and ov5640_sensor_resume() fails, sensor->ctrls.handler should be released, otherwise a memory leak will be detected: unreferenced object 0xc674ca80 (size 64): comm "swapper/0", pid 1, jiffies 4294938337 (age 204.880s) hex dump (first 32 bytes): 80 55 75 c6 80 54 75 c6 00 55 75 c6 80 52 75 c6 .Uu..Tu..Uu..Ru. 00 53 75 c6 00 00 00 00 00 00 00 00 00 00 00 00 .Su.......... Fixes: 85644a9b ("media: ov5640: Use runtime PM") Signed-off-by:
Xiaolei Wang <xiaolei.wang@windriver.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Christophe JAILLET authored
[ Upstream commit 0822315e ] This is odd to have a of_node_put() just after a for_each_child_of_node() or a for_each_endpoint_of_node() loop. It should already be called during the last iteration. Remove these calls. Fixes: 66d8c9d2 ("media: i2c: Add MAX9286 driver") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Guoniu.zhou authored
[ Upstream commit 8fc29e3c ] The value of V4L2_CID_VBLANK control is initialized to default vblank value of 640x480 when driver probe. When OV5640 work at DVP mode, the control value won't update and lead to sensor can't output data if the resolution remain the same as last time since incorrect total vertical size. So update it when there is a new value applied. Fixes: bce93b82 ("media: ov5640: Add VBLANK control") Signed-off-by:
Guoniu.zhou <guoniu.zhou@nxp.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jacopo Mondi authored
[ Upstream commit eeaa47d1 ] The ov5640_update_pixel_rate() function handles the parallel and MIPI CSI-2 cases separately. When running on a parallel setup the V4L2_CID_PIXEL_RATE value is calculated at the beginning of the function using the values configured with the frame_interval operations, and then the function immediately returns. The remaining of the function handles the MIPI CSI-2 configuration and should not use the 'current_fr' and 'def_fps' fields as those are only relevant for parallel mode. Drop a small section of dead code that updates vblank using frame_interval on a MIPI CSI-2 setup. Signed-off-by:
Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Stable-dep-of: 8fc29e3c ("media: ov5640: fix vblank unchange issue when work at dvp mode") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Marek Vasut authored
[ Upstream commit 6e481d52 ] In case of encoded input VP9 data width that is not multiple of macroblock size, which is 16 (e.g. 1080x1920 frames, where 1080 is multiple of 8), the width is padded to be a multiple of macroblock size (for 1080x1920 frames, that is 1088x1920). The hantro_postproc_g2_enable() checks whether the encoded data width is equal to decoded frame width, and if not, enables down-scale mode. For a frame where input is 1080x1920 and output is 1088x1920, this is incorrect as no down-scale happens, the frame is only padded. Enabling the down-scale mode in this case results in corrupted frames. Fix this by adjusting the check to test whether encoded data width is greater than decoded frame width, and only in that case enable the down-scale mode. To generate input test data to trigger this bug, use e.g.: $ gst-launch-1.0 videotestsrc ! video/x-raw,width=272,height=256,format=I420 ! \ vp9enc ! matroskamux ! filesink location=/tmp/test.vp9 To trigger the bug upon decoding (note that the NV12 must be forced, as that assures the output data would pass the G2 postproc): $ gst-launch-1.0 filesrc location=/tmp/test.vp9 ! matroskademux ! vp9parse ! \ v4l2slvp9dec ! video/x-raw,format=NV12 ! videoconvert ! fbdevsink Fixes: 79c987de ("media: hantro: Use post processor scaling capacities") Signed-off-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Marek Vasut authored
[ Upstream commit 88d4b23a ] The i.MX8MM/N/P does not define the .reset op since reset of the VPU is done by genpd. Check whether the .reset op is defined before calling it to avoid NULL pointer dereference. Note that the Fixes tag is set to the commit which removed the reset op from i.MX8M Hantro G2 implementation, this is because before this commit all the implementations did define the .reset op. Fixes: 6971efb7 ("media: hantro: Allow i.MX8MQ G1 and G2 to run independently") Signed-off-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Tested-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
Adam Ford <aford173@gmail.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Yang Yingliang authored
[ Upstream commit 99e12410 ] Afer commit 1fa5ae85 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically. Therefore, it needs to be freed, which is done by the driver core for us once all references to the device are gone. Therefore, move the dev_set_name() call immediately before the call device_register(), which either succeeds (then the freeing will be done upon subsequent remvoal), or puts the reference in the error call. Also, it is not unusual that the return value of dev_set_name is not checked. Fixes: 1fa5ae85 ("driver core: get rid of struct device's bus_id string array") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> [linux@dominikbrodowski.net: simplification, commit message modified] Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Yang Yingliang authored
[ Upstream commit 402ab979 ] As the comment of device_register() says, it should use put_device() to give up the reference in the error path. Then, insofar resources will be freed in pcmcia_release_dev(), the error path is no longer needed. In particular, this means that the (previously missing) dropping of the reference to &p_dev->function_config->ref is now handled by pcmcia_release_dev(). Fixes: 360b65b9 ("[PATCH] pcmcia: make config_t independent, add reference counting") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> [linux@dominikbrodowski.net: simplification, commit message rewrite] Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Yang Yingliang authored
[ Upstream commit e3ea1b48 ] If device_register() returns error in pccardd(), it leads two issues: 1. The socket_released has never been completed, it will block pcmcia_unregister_socket(), because of waiting for completion of socket_released. 2. The device name allocated by dev_set_name() is leaked. Fix this two issues by calling put_device() when device_register() fails. socket_released can be completed in pcmcia_release_socket(), the name can be freed in kobject_cleanup(). Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Javier Carrasco authored
[ Upstream commit 2be36c09 ] The current implementation passes PIN_IO_INTA_OUT (2) as a mask and PIN_IO_INTAPM (GENMASK(1, 0)) as a value. Swap the variables to assign mask and value the right way. This error was first introduced with the alarm support. For better or worse it worked as expected because 0x02 was applied as a mask to 0x03, resulting 0x02 anyway. This will of course not work for any other value. Fixes: e5aac267 ("rtc: pcf85363: add alarm support") Signed-off-by:
Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20231013-topic-pcf85363_regmap_update_bits-v1-1-c454f016f71f@gmail.com Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dan Williams authored
[ Upstream commit db10cb9b ] CONFIG_DEBUG_SG highlights that get_{report,ext_report,derived_key)()} are passing stack buffers as the @req_buf argument to handle_guest_request(), generating a Call Trace of the following form: WARNING: CPU: 0 PID: 1175 at include/linux/scatterlist.h:187 enc_dec_message+0x518/0x5b0 [sev_guest] [..] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 RIP: 0010:enc_dec_message+0x518/0x5b0 [sev_guest] Call Trace: <TASK> [..] handle_guest_request+0x135/0x520 [sev_guest] get_ext_report+0x1ec/0x3e0 [sev_guest] snp_guest_ioctl+0x157/0x200 [sev_guest] Note that the above Call Trace was with the DEBUG_SG BUG_ON()s converted to WARN_ON()s. This is benign as long as there are no hardware crypto accelerators loaded for the aead cipher, and no subsequent dma_map_sg() is performed on the scatterlist. However, sev-guest can not assume the presence of an aead accelerator nor can it assume that CONFIG_DEBUG_SG is disabled. Resolve this bug by allocating virt_addr_valid() memory, similar to the other buffers am @snp_dev instance carries, to marshal requests from user buffers to kernel buffers. Reported-by:
Peter Gonda <pgonda@google.com> Closes: http://lore.kernel.org/r/CAMkAt6r2VPPMZ__SQfJse8qWsUyYW3AgYbOUVM0S_Vtk=KvkxQ@mail.gmail.com Fixes: fce96cf0 ("virt: Add SEV-SNP guest driver") Cc: Borislav Petkov <bp@alien8.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Dionna Glaze <dionnaglaze@google.com> Cc: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> Tested-by:
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dionna Glaze authored
[ Upstream commit 0144e3b8 ] The GHCB specification declares that the firmware error value for a guest request will be stored in the lower 32 bits of EXIT_INFO_2. The upper 32 bits are for the VMM's own error code. The fw_err argument to snp_guest_issue_request() is thus a misnomer, and callers will need access to all 64 bits. The type of unsigned long also causes problems, since sw_exit_info2 is u64 (unsigned long long) vs the argument's unsigned long*. Change this type for issuing the guest request. Pass the ioctl command struct's error field directly instead of in a local variable, since an incomplete guest request may not set the error code, and uninitialized stack memory would be written back to user space. The firmware might not even be called, so bookend the call with the no firmware call error and clear the error. Since the "fw_err" field is really exitinfo2 split into the upper bits' vmm error code and lower bits' firmware error code, convert the 64 bit value to a union. [ bp: - Massage commit message - adjust code - Fix a build issue as Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202303070609.vX6wp2Af-lkp@intel.com - print exitinfo2 in hex Tom: - Correct -EIO exit case. ] Signed-off-by:
Dionna Glaze <dionnaglaze@google.com> Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230214164638.1189804-5-dionnaglaze@google.com Link: https://lore.kernel.org/r/20230307192449.24732-12-bp@alien8.de Stable-dep-of: db10cb9b ("virt: sevguest: Fix passing a stack buffer as a scatterlist target") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Peter Gonda authored
[ Upstream commit efb339a8 ] The PSP can return a "firmware error" code of -1 in circumstances where the PSP has not actually been called. To make this protocol unambiguous, name the value SEV_RET_NO_FW_CALL. [ bp: Massage a bit. ] Signed-off-by:
Peter Gonda <pgonda@google.com> Signed-off-by:
Dionna Glaze <dionnaglaze@google.com> Signed-off-by:
Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20221207010210.2563293-2-dionnaglaze@google.com Stable-dep-of: db10cb9b ("virt: sevguest: Fix passing a stack buffer as a scatterlist target") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dan Williams authored
[ Upstream commit 88d3917f ] Ira reports that removing cxl_mock_mem causes a crash with the following trace: BUG: kernel NULL pointer dereference, address: 0000000000000044 [..] RIP: 0010:cxl_region_decode_reset+0x7f/0x180 [cxl_core] [..] Call Trace: <TASK> cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x29/0x40 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 bus_remove_device+0xd7/0x150 device_del+0x155/0x3e0 device_unregister+0x13/0x60 devm_release_action+0x4d/0x90 ? __pfx_unregister_port+0x10/0x10 [cxl_core] delete_endpoint+0x121/0x130 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 bus_remove_device+0xd7/0x150 device_del+0x155/0x3e0 ? lock_release+0x142/0x290 cdev_device_del+0x15/0x50 cxl_memdev_unregister+0x54/0x70 [cxl_core] This crash is due to the clearing out the cxl_memdev's driver context (@cxlds) before the subsystem is done with it. This is ultimately due to the region(s), that this memdev is a member, being torn down and expecting to be able to de-reference @cxlds, like here: static int cxl_region_decode_reset(struct cxl_region *cxlr, int count) ... if (cxlds->rcd) goto endpoint_reset; ... Fix it by keeping the driver context valid until memdev-device unregistration, and subsequently the entire stack of related dependencies, unwinds. Fixes: 9cc238c7 ("cxl/pci: Introduce cdevm_file_operations") Reported-by:
Ira Weiny <ira.weiny@intel.com> Reviewed-by:
Davidlohr Bueso <dave@stgolabs.net> Reviewed-by:
Dave Jiang <dave.jiang@intel.com> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by:
Ira Weiny <ira.weiny@intel.com> Tested-by:
Ira Weiny <ira.weiny@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dinghao Liu authored
[ Upstream commit cab63f64 ] put_device() needs to be called on failure of device_register() to give up the reference initialized in it to avoid refcount leak. Fixes: 3a379bbc ("i3c: Add core I3C infrastructure") Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Link: https://lore.kernel.org/r/20230921082410.25548-1-dinghao.liu@zju.edu.cn Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hangyu Hua authored
[ Upstream commit ce070879 ] When p9pdu_readf() is called with "s?d" attribute, it allocates a pointer that will store a string. But when p9pdu_readf() fails while handling "d" then this pointer will not be freed in p9_check_errors(). Fixes: 51a87c55 ("9p: rework client code to use new protocol support functions") Reviewed-by:
Christian Schoenebeck <linux_oss@crudebyte.com> Signed-off-by:
Hangyu Hua <hbh25y@gmail.com> Message-ID: <20231027030302.11927-1-hbh25y@gmail.com> Signed-off-by:
Dominique Martinet <asmadeus@codewreck.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ian Rogers authored
[ Upstream commit c1149037 ] Caught using reference count checking on perf top with "--call-graph=lbr". After this no memory leaks were detected. Fixes: 57849998 ("perf report: Add processing for cycle histograms") Signed-off-by:
Ian Rogers <irogers@google.com> Cc: K Prateek Nayak <kprateek.nayak@amd.com> Cc: Ravi Bangoria <ravi.bangoria@amd.com> Cc: Sandipan Das <sandipan.das@amd.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: German Gomez <german.gomez@arm.com> Cc: James Clark <james.clark@arm.com> Cc: Nick Terrell <terrelln@fb.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Changbin Du <changbin.du@huawei.com> Cc: liuwenyu <liuwenyu7@huawei.com> Cc: Yang Jihong <yangjihong1@huawei.com> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Miguel Ojeda <ojeda@kernel.org> Cc: Song Liu <song@kernel.org> Cc: Leo Yan <leo.yan@linaro.org> Cc: Kajol Jain <kjain@linux.ibm.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com> Cc: Yanteng Si <siyanteng@loongson.cn> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Link: https://lore.kernel.org/r/20231024222353.3024098-6-irogers@google.com Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-