- Kernel - mailweb.openeuler.org

[openeuler:openEuler-1.0-LTS 13425/21785] drivers/net/ethernet/huawei/hinic/hinic_main.c:249:23: error: implicit declaration of function 'vlan_dev_priv'; did you mean 'netdev_priv'?
by kernel test robot 09 Mar '24

09 Mar '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 3d10c870b322e5d1a4f8fb923b879a0b73246157 commit: 90f09a01314abe26de1a722d1b51c351d84e1f5b [13425/21785] net/hinic: Add support for X86 Arch config: x86_64-randconfig-015-20240308 (https://download.01.org/0day-ci/archive/20240309/202403091438.ZbJbSAui-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240309/202403091438.ZbJbSAui-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202403091438.ZbJbSAui-lkp@intel.com/ All errors (new ones prefixed by >>): drivers/net/ethernet/huawei/hinic/hinic_main.c: In function 'hinic_netdev_event': >> drivers/net/ethernet/huawei/hinic/hinic_main.c:249:23: error: implicit declaration of function 'vlan_dev_priv'; did you mean 'netdev_priv'? [-Werror=implicit-function-declaration] 249 | ret = vlan_dev_priv(ndev)->real_dev; | ^~~~~~~~~~~~~ | netdev_priv >> drivers/net/ethernet/huawei/hinic/hinic_main.c:249:42: error: invalid type argument of '->' (have 'int') 249 | ret = vlan_dev_priv(ndev)->real_dev; | ^~ drivers/net/ethernet/huawei/hinic/hinic_main.c:251:49: error: invalid type argument of '->' (have 'int') 251 | ret = vlan_dev_priv(ret)->real_dev; | ^~ drivers/net/ethernet/huawei/hinic/hinic_main.c: At top level: drivers/net/ethernet/huawei/hinic/hinic_main.c:3294:6: warning: no previous prototype for 'nic_event' [-Wmissing-prototypes] 3294 | void nic_event(struct hinic_lld_dev *lld_dev, void *adapter, | ^~~~~~~~~ cc1: some warnings being treated as errors vim +249 drivers/net/ethernet/huawei/hinic/hinic_main.c edd384f682cc29 Aviad Krawczyk 2017-08-21 221 6cb2e756917d12 Xue 2019-01-31 222 #define HINIC_MAX_VLAN_DEPTH_OFFLOAD_SUPPORT 2 6cb2e756917d12 Xue 2019-01-31 223 #define HINIC_VLAN_CLEAR_OFFLOAD (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | \ 6cb2e756917d12 Xue 2019-01-31 224 NETIF_F_SCTP_CRC | NETIF_F_RXCSUM | \ 6cb2e756917d12 Xue 2019-01-31 225 NETIF_F_ALL_TSO) edd384f682cc29 Aviad Krawczyk 2017-08-21 226 6cb2e756917d12 Xue 2019-01-31 227 int hinic_netdev_event(struct notifier_block *notifier, 6cb2e756917d12 Xue 2019-01-31 228 unsigned long event, void *ptr) edd384f682cc29 Aviad Krawczyk 2017-08-21 229 { 6cb2e756917d12 Xue 2019-01-31 230 struct net_device *ndev = netdev_notifier_info_to_dev(ptr); 6cb2e756917d12 Xue 2019-01-31 231 struct net_device *real_dev, *ret; 6cb2e756917d12 Xue 2019-01-31 232 struct hinic_nic_dev *nic_dev; 6cb2e756917d12 Xue 2019-01-31 233 u16 vlan_depth; 6cb2e756917d12 Xue 2019-01-31 234 6cb2e756917d12 Xue 2019-01-31 235 if (!is_vlan_dev(ndev)) 6cb2e756917d12 Xue 2019-01-31 236 return NOTIFY_DONE; 6cb2e756917d12 Xue 2019-01-31 237 6cb2e756917d12 Xue 2019-01-31 238 dev_hold(ndev); 6cb2e756917d12 Xue 2019-01-31 239 6cb2e756917d12 Xue 2019-01-31 240 switch (event) { 6cb2e756917d12 Xue 2019-01-31 241 case NETDEV_REGISTER: 6cb2e756917d12 Xue 2019-01-31 242 real_dev = vlan_dev_real_dev(ndev); 6cb2e756917d12 Xue 2019-01-31 243 nic_dev = hinic_get_uld_dev_by_ifname(real_dev->name, 6cb2e756917d12 Xue 2019-01-31 244 SERVICE_T_NIC); 6cb2e756917d12 Xue 2019-01-31 245 if (!nic_dev) 6cb2e756917d12 Xue 2019-01-31 246 goto out; 6cb2e756917d12 Xue 2019-01-31 247 6cb2e756917d12 Xue 2019-01-31 248 vlan_depth = 1; 6cb2e756917d12 Xue 2019-01-31 @249 ret = vlan_dev_priv(ndev)->real_dev; 6cb2e756917d12 Xue 2019-01-31 250 while (is_vlan_dev(ret)) { 6cb2e756917d12 Xue 2019-01-31 251 ret = vlan_dev_priv(ret)->real_dev; 6cb2e756917d12 Xue 2019-01-31 252 vlan_depth++; 6cb2e756917d12 Xue 2019-01-31 253 } 6cb2e756917d12 Xue 2019-01-31 254 6cb2e756917d12 Xue 2019-01-31 255 if (vlan_depth == HINIC_MAX_VLAN_DEPTH_OFFLOAD_SUPPORT) { 6cb2e756917d12 Xue 2019-01-31 256 ndev->vlan_features &= (~HINIC_VLAN_CLEAR_OFFLOAD); 6cb2e756917d12 Xue 2019-01-31 257 } else if (vlan_depth > HINIC_MAX_VLAN_DEPTH_OFFLOAD_SUPPORT) { 6cb2e756917d12 Xue 2019-01-31 258 #ifdef HAVE_NDO_SET_FEATURES 6cb2e756917d12 Xue 2019-01-31 259 #ifdef HAVE_RHEL6_NET_DEVICE_OPS_EXT 6cb2e756917d12 Xue 2019-01-31 260 set_netdev_hw_features(ndev, 6cb2e756917d12 Xue 2019-01-31 261 get_netdev_hw_features(ndev) & 6cb2e756917d12 Xue 2019-01-31 262 (~HINIC_VLAN_CLEAR_OFFLOAD)); 6cb2e756917d12 Xue 2019-01-31 263 #else 6cb2e756917d12 Xue 2019-01-31 264 ndev->hw_features &= (~HINIC_VLAN_CLEAR_OFFLOAD); 6cb2e756917d12 Xue 2019-01-31 265 #endif 6cb2e756917d12 Xue 2019-01-31 266 #endif 6cb2e756917d12 Xue 2019-01-31 267 ndev->features &= (~HINIC_VLAN_CLEAR_OFFLOAD); 6cb2e756917d12 Xue 2019-01-31 268 } edd384f682cc29 Aviad Krawczyk 2017-08-21 269 6cb2e756917d12 Xue 2019-01-31 270 break; edd384f682cc29 Aviad Krawczyk 2017-08-21 271 6cb2e756917d12 Xue 2019-01-31 272 default: 6cb2e756917d12 Xue 2019-01-31 273 break; 6cb2e756917d12 Xue 2019-01-31 274 }; edd384f682cc29 Aviad Krawczyk 2017-08-21 275 6cb2e756917d12 Xue 2019-01-31 276 out: 6cb2e756917d12 Xue 2019-01-31 277 dev_put(ndev); edd384f682cc29 Aviad Krawczyk 2017-08-21 278 6cb2e756917d12 Xue 2019-01-31 279 return NOTIFY_DONE; edd384f682cc29 Aviad Krawczyk 2017-08-21 280 } 6cb2e756917d12 Xue 2019-01-31 281 #endif edd384f682cc29 Aviad Krawczyk 2017-08-21 282 :::::: The code at line 249 was first introduced by commit :::::: 6cb2e756917d122560e0c52f350682760d004eec net: hinic: Add NIC Layer :::::: TO: Xue <xuechaojing(a)huawei.com> :::::: CC: Xie XiuQi <xiexiuqi(a)huawei.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
by Li Huafei 09 Mar '24

09 Mar '24

From: Hans de Goede <hdegoede(a)redhat.com> stable inclusion from stable-v4.19.297 commit 44481b244fcaa2b895a53081d6204c574720c38c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94P85 CVE: CVE-2023-52478 --------------------------- commit dac501397b9d81e4782232c39f94f4307b137452 upstream. hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: power_supply_unregister+0x8e/0xa0 Sep 22 20:01:35 eric kernel: release_nodes+0x3d/0xb0 Sep 22 20:01:35 eric kernel: devres_release_group+0xfc/0x130 Sep 22 20:01:35 eric kernel: hid_device_remove+0x56/0xa0 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? __queue_work+0x1df/0x440 Sep 22 20:01:35 eric kernel: hid_destroy_device+0x4b/0x60 Sep 22 20:01:35 eric kernel: logi_dj_remove+0x9a/0x100 [hid_logitech_dj 5c91534a0ead2b65e04dd799a0437e3b99b21bc4] Sep 22 20:01:35 eric kernel: hid_device_remove+0x44/0xa0 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? __queue_work+0x1df/0x440 Sep 22 20:01:35 eric kernel: hid_destroy_device+0x4b/0x60 Sep 22 20:01:35 eric kernel: usbhid_disconnect+0x47/0x60 [usbhid 727dcc1c0b94e6b4418727a468398ac3bca492f3] Sep 22 20:01:35 eric kernel: usb_unbind_interface+0x90/0x270 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? kobject_put+0xa0/0x1d0 Sep 22 20:01:35 eric kernel: usb_disable_device+0xcd/0x1e0 Sep 22 20:01:35 eric kernel: usb_disconnect+0xde/0x2c0 Sep 22 20:01:35 eric kernel: usb_disconnect+0xc3/0x2c0 Sep 22 20:01:35 eric kernel: hub_event+0xe80/0x1c10 There have been quite a few bug reports (see Link tags) about this crash. Fix all the TOCTOU issues, including the really bad power-supply related system crash on USB disconnect, by making probe() use the workqueue for running hidpp_connect_event() too, so that it can never run more then once. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227221 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2242189 Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412#c58 Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Link: https://lore.kernel.org/r/20231005182638.3776-1-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/hid/hid-logitech-hidpp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index 504e8917b06f..eda8833b8c7f 100644 --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c @@ -3080,7 +3080,8 @@ static int hidpp_probe(struct hid_device *hdev, const struct hid_device_id *id) /* Allow incoming packets */ hid_device_io_start(hdev); - hidpp_connect_event(hidpp); + schedule_work(&hidpp->work); + flush_work(&hidpp->work); return ret; -- 2.25.1

2 1

[PATCH OLK-5.10] wifi: mac80211: fix potential key use-after-free
by Dong Chenchen 09 Mar '24

09 Mar '24

From: Johannes Berg <johannes.berg(a)intel.com> mainline inclusion from mainline-v5.12-rc6 commit 31db78a4923ef5e2008f2eed321811ca79e7f71b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95ASP CVE: CVE-2023-52530 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK protection (identical key reinstall), ieee80211_gtk_rekey_add() will still return a pointer into the key, in a potential use-after-free. This normally doesn't happen since it's only called by iwlwifi in case of WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers of ieee80211_gtk_rekey_add(). Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything") Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Conflicts: net/mac80211/cfg.c Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/mac80211/cfg.c | 3 +++ net/mac80211/key.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index c6a7f1c99abc..70126518ad16 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -509,6 +509,9 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev, sta->cipher_scheme = cs; err = ieee80211_key_link(key, sdata, sta); + /* KRACK protection, shouldn't happen but just silently accept key */ + if (err == -EALREADY) + err = 0; out_unlock: mutex_unlock(&local->sta_mtx); diff --git a/net/mac80211/key.c b/net/mac80211/key.c index 6a72c33679ba..6b089594a9f3 100644 --- a/net/mac80211/key.c +++ b/net/mac80211/key.c @@ -843,7 +843,7 @@ int ieee80211_key_link(struct ieee80211_key *key, */ if (ieee80211_key_identical(sdata, old_key, key)) { ieee80211_key_free_unused(key); - ret = 0; + ret = -EALREADY; goto out; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] wifi: mac80211: fix potential key use-after-free
by Dong Chenchen 09 Mar '24

09 Mar '24

From: Johannes Berg <johannes.berg(a)intel.com> mainline inclusion from mainline-v5.12-rc6 commit 31db78a4923ef5e2008f2eed321811ca79e7f71b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95ASP CVE: CVE-2023-52530 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK protection (identical key reinstall), ieee80211_gtk_rekey_add() will still return a pointer into the key, in a potential use-after-free. This normally doesn't happen since it's only called by iwlwifi in case of WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers of ieee80211_gtk_rekey_add(). Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything") Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Conflicts: net/mac80211/cfg.c Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/mac80211/cfg.c | 3 +++ net/mac80211/key.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index e46944500cfa..2201923238ed 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -457,6 +457,9 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev, sta->cipher_scheme = cs; err = ieee80211_key_link(key, sdata, sta); + /* KRACK protection, shouldn't happen but just silently accept key */ + if (err == -EALREADY) + err = 0; out_unlock: mutex_unlock(&local->sta_mtx); diff --git a/net/mac80211/key.c b/net/mac80211/key.c index 6775d6cb7d3d..017a9d2b5cec 100644 --- a/net/mac80211/key.c +++ b/net/mac80211/key.c @@ -681,7 +681,7 @@ int ieee80211_key_link(struct ieee80211_key *key, */ if (ieee80211_key_identical(sdata, old_key, key)) { ieee80211_key_free_unused(key); - ret = 0; + ret = -EALREADY; goto out; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS v1 0/6] Fix CVE-2023-52514
by Wei Li 09 Mar '24

09 Mar '24

This series is meant to fix CVE-2023-52514, with 5 LTS patches which are depended on but not backported before. Sean Christopherson (6): x86/reboot: Force all cpus to exit VMX root if VMX is supported x86/virt: Force GIF=1 prior to disabling SVM (for reboot flows) x86/crash: Disable virt in core NMI crash handler to avoid double shootdown x86/reboot: Disable virtualization in an emergency if SVM is supported x86/reboot: Disable SVM, not just VMX, when stopping CPUs x86/reboot: VMCLEAR active VMCSes before emergency reboot arch/x86/include/asm/kexec.h | 2 - arch/x86/include/asm/reboot.h | 4 ++ arch/x86/include/asm/virtext.h | 16 ++++- arch/x86/kernel/crash.c | 47 +------------ arch/x86/kernel/reboot.c | 121 ++++++++++++++++++++++++--------- arch/x86/kernel/smp.c | 6 +- arch/x86/kvm/vmx.c | 12 +--- 7 files changed, 112 insertions(+), 96 deletions(-) -- 2.25.1

2 7

[PATCH openEuler-1.0-LTS] drm: bridge/panel: Cleanup connector on bridge detach
by Guo Mengqi 09 Mar '24

09 Mar '24

From: Paul Cercueil <paul(a)crapouillou.net> stable inclusion from stable-v5.10.37 commit ce450934a00cf896e648fde08d0bd1426653d7a2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94VOL CVE: CVE-2021-47063 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4d906839d321c2efbf3fed4bc31ffd9ff55b75c0 upstream. If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev) directly in if() block Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.") Cc: <stable(a)vger.kernel.org> # 4.12+ Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Neil Armstrong <narmstrong(a)baylibre.com> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Jonas Karlman <jonas(a)kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec(a)siol.net> Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-2-paul@c… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> conflicts: drivers/gpu/drm/bridge/panel.c Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/gpu/drm/bridge/panel.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c index 7cbaba213ef6..dbeaf1257668 100644 --- a/drivers/gpu/drm/bridge/panel.c +++ b/drivers/gpu/drm/bridge/panel.c @@ -92,6 +92,17 @@ static int panel_bridge_attach(struct drm_bridge *bridge) static void panel_bridge_detach(struct drm_bridge *bridge) { struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge); + struct drm_connector *connector = &panel_bridge->connector; + + /* + * Cleanup the connector if we know it was initialized. + * + * FIXME: This wouldn't be needed if the panel_bridge structure was + * allocated with drmm_kzalloc(). This might be tricky since the + * drm_device pointer can only be retrieved when the bridge is attached. + */ + if (connector->dev) + drm_connector_cleanup(connector); drm_panel_detach(panel_bridge->panel); } -- 2.17.1

2 1

[PATCH OLK-5.10 0/3] fix CVE-2023-52578
by Zhengchao Shao 09 Mar '24

09 Mar '24

fix CVE-2023-52578 Eric Dumazet (2): net: add atomic_long_t to net_device_stats fields net: bridge: use DEV_STATS_INC() Felix Riemann (1): net: Fix unwanted sign extension in netdev_stats_to_stats64() include/linux/netdevice.h | 58 +++++++++++++++++++++++---------------- include/net/dst.h | 5 ++-- net/bridge/br_forward.c | 4 +-- net/bridge/br_input.c | 4 +-- net/core/dev.c | 14 ++-------- 5 files changed, 44 insertions(+), 41 deletions(-) -- 2.34.1

2 4

[PATCH openEuler-1.0-LTS] uio_hv_generic: Fix a memory leak in error handling paths
by Guo Mengqi 09 Mar '24

09 Mar '24

From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> stable inclusion from stable-v5.10.40 commit d84b5e912212b05f6b5bde9f682046accfbe0354 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I956GH CVE: CVE-2021-47071 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 3ee098f96b8b6c1a98f7f97915f8873164e6af9d upstream. If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be updated and 'hv_uio_cleanup()' in the error handling path will not be able to free the corresponding buffer. In such a case, we need to free the buffer explicitly. Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Link: https://lore.kernel.org/r/4fdaff557deef6f0475d02ba7922ddbaa1ab08a6.16205440… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/uio/uio_hv_generic.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c index 170fa1f8f00e..b58e7c582d3f 100644 --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -250,8 +250,10 @@ hv_uio_probe(struct hv_device *dev, ret = vmbus_establish_gpadl(dev->channel, pdata->recv_buf, RECV_BUFFER_SIZE, &pdata->recv_gpadl); - if (ret) + if (ret) { + vfree(pdata->recv_buf); goto fail_close; + } /* put Global Physical Address Label in name */ snprintf(pdata->recv_name, sizeof(pdata->recv_name), @@ -271,8 +273,10 @@ hv_uio_probe(struct hv_device *dev, ret = vmbus_establish_gpadl(dev->channel, pdata->send_buf, SEND_BUFFER_SIZE, &pdata->send_gpadl); - if (ret) + if (ret) { + vfree(pdata->send_buf); goto fail_close; + } snprintf(pdata->send_name, sizeof(pdata->send_name), "send:%u", pdata->send_gpadl); -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS 0/3] fix CVE-2023-52578
by Zhengchao Shao 09 Mar '24

09 Mar '24

Fix CVE-2023-52578 Eric Dumazet (2): net: add atomic_long_t to net_device_stats fields net: bridge: use DEV_STATS_INC() Felix Riemann (1): net: Fix unwanted sign extension in netdev_stats_to_stats64() include/linux/netdevice.h | 58 +++++++++++++++++++++++---------------- include/net/dst.h | 5 ++-- net/bridge/br_forward.c | 4 +-- net/bridge/br_input.c | 4 +-- net/core/dev.c | 14 ++-------- 5 files changed, 44 insertions(+), 41 deletions(-) -- 2.34.1

2 4

[PATCH OLK-5.10] RDMA/rxe: Return CQE error if invalid lkey was supplied
by Liu Jian 09 Mar '24

09 Mar '24

From: Leon Romanovsky <leonro(a)nvidia.com> mainline inclusion from mainline-v5.13-rc3 commit dc07628bd2bbc1da768e265192c28ebd301f509d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I956FT CVE: CVE-2021-47076 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- RXE is missing update of WQE status in LOCAL_WRITE failures. This caused the following kernel panic if someone sent an atomic operation with an explicitly wrong lkey. [leonro@vm ~]$ mkt test test_atomic_invalid_lkey (tests.test_atomic.AtomicTest) ... WARNING: CPU: 5 PID: 263 at drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Modules linked in: crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core ptp pps_core CPU: 5 PID: 263 Comm: python3 Not tainted 5.13.0-rc1+ #2936 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Code: 03 0f 8e 65 0e 00 00 3b 93 10 06 00 00 0f 84 82 0a 00 00 4c 89 ff 4c 89 44 24 38 e8 2d 74 a9 e1 4c 8b 44 24 38 e9 1c f5 ff ff <0f> 0b e9 0c e8 ff ff b8 05 00 00 00 41 bf 05 00 00 00 e9 ab e7 ff RSP: 0018:ffff8880158af090 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652 RDX: 1ffff9200004b442 RSI: 0000000000000004 RDI: ffffc9000025a210 RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b R10: ffffed1002c2ee81 R11: 0000000000000007 R12: ffff88800f3b63e8 R13: ffff888016a78008 R14: ffffc9000025a180 R15: 000000000000000c FS: 00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0xb11/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_responder+0x5532/0x7620 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0x9c8/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_requester+0x1efd/0x58c0 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_post_send+0x998/0x1860 [rdma_rxe] ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs] ib_uverbs_write+0x847/0xc80 [ib_uverbs] vfs_write+0x1c5/0x840 ksys_write+0x176/0x1d0 do_syscall_64+0x3f/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/11e7b553f3a6f5371c6bb3f57c494bb52b88af99.16207117… Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> Acked-by: Zhu Yanjun <zyjzyj2000(a)gmail.com> Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> Signed-off-by: Liu Jian <liujian56(a)huawei.com> Conflicts: drivers/infiniband/sw/rxe/rxe_comp.c --- drivers/infiniband/sw/rxe/rxe_comp.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/sw/rxe/rxe_comp.c b/drivers/infiniband/sw/rxe/rxe_comp.c index 0a1e6393250b..aa73a54ea070 100644 --- a/drivers/infiniband/sw/rxe/rxe_comp.c +++ b/drivers/infiniband/sw/rxe/rxe_comp.c @@ -346,13 +346,15 @@ static inline enum comp_state do_read(struct rxe_qp *qp, ret = copy_data(qp->pd, IB_ACCESS_LOCAL_WRITE, &wqe->dma, payload_addr(pkt), payload_size(pkt), to_mem_obj, NULL); - if (ret) + if (ret) { + wqe->status = IB_WC_LOC_PROT_ERR; return COMPST_ERROR; + } if (wqe->dma.resid == 0 && (pkt->mask & RXE_END_MASK)) return COMPST_COMP_ACK; - else - return COMPST_UPDATE_COMP; + + return COMPST_UPDATE_COMP; } static inline enum comp_state do_atomic(struct rxe_qp *qp, @@ -366,10 +368,12 @@ static inline enum comp_state do_atomic(struct rxe_qp *qp, ret = copy_data(qp->pd, IB_ACCESS_LOCAL_WRITE, &wqe->dma, &atomic_orig, sizeof(u64), to_mem_obj, NULL); - if (ret) + if (ret) { + wqe->status = IB_WC_LOC_PROT_ERR; return COMPST_ERROR; - else - return COMPST_COMP_ACK; + } + + return COMPST_COMP_ACK; } static void make_send_cqe(struct rxe_qp *qp, struct rxe_send_wqe *wqe, -- 2.34.1

2 1

2024

2023

2022

2021

2020

2019

Kernel