- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable()
by Hui Tang 05 Jul '24

05 Jul '24

From: Tuo Li <islituo(a)gmail.com> mainline inclusion from mainline-v6.6-rc1 commit 2e63972a2de14482d0eae1a03a73e379f1c3f44c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917IV CVE: CVE-2024-22386 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ----------------------------------- The variable crtc->state->event is often protected by the lock crtc->dev->event_lock when is accessed. However, it is accessed as a condition of an if statement in exynos_drm_crtc_atomic_disable() without holding the lock: if (crtc->state->event && !crtc->state->active) However, if crtc->state->event is changed to NULL by another thread right after the conditions of the if statement is checked to be true, a null-pointer dereference can occur in drm_crtc_send_vblank_event(): e->pipe = pipe; To fix this possible null-pointer dereference caused by data race, the spin lock coverage is extended to protect the if statement as well as the function call to drm_crtc_send_vblank_event(). Reported-by: BassCheck <bass(a)buaa.edu.cn> Link: https://sites.google.com/view/basscheck/home Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Added relevant link. Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: Hui Tang <tanghui20(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 2696289ecc78..b3e23ace5869 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -43,13 +43,12 @@ static void exynos_drm_crtc_atomic_disable(struct drm_crtc *crtc, if (exynos_crtc->ops->disable) exynos_crtc->ops->disable(exynos_crtc); + spin_lock_irq(&crtc->dev->event_lock); if (crtc->state->event && !crtc->state->active) { - spin_lock_irq(&crtc->dev->event_lock); drm_crtc_send_vblank_event(crtc, crtc->state->event); - spin_unlock_irq(&crtc->dev->event_lock); - crtc->state->event = NULL; } + spin_unlock_irq(&crtc->dev->event_lock); } static int exynos_crtc_atomic_check(struct drm_crtc *crtc, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable()
by Hui Tang 05 Jul '24

05 Jul '24

From: Tuo Li <islituo(a)gmail.com> stable inclusion from stable-v6.6-rc1 commit 2e63972a2de14482d0eae1a03a73e379f1c3f44c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917IV CVE: CVE-2024-22386 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- The variable crtc->state->event is often protected by the lock crtc->dev->event_lock when is accessed. However, it is accessed as a condition of an if statement in exynos_drm_crtc_atomic_disable() without holding the lock: if (crtc->state->event && !crtc->state->active) However, if crtc->state->event is changed to NULL by another thread right after the conditions of the if statement is checked to be true, a null-pointer dereference can occur in drm_crtc_send_vblank_event(): e->pipe = pipe; To fix this possible null-pointer dereference caused by data race, the spin lock coverage is extended to protect the if statement as well as the function call to drm_crtc_send_vblank_event(). Reported-by: BassCheck <bass(a)buaa.edu.cn> Link: https://sites.google.com/view/basscheck/home Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Added relevant link. Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: Hui Tang <tanghui20(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 2696289ecc78..b3e23ace5869 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -43,13 +43,12 @@ static void exynos_drm_crtc_atomic_disable(struct drm_crtc *crtc, if (exynos_crtc->ops->disable) exynos_crtc->ops->disable(exynos_crtc); + spin_lock_irq(&crtc->dev->event_lock); if (crtc->state->event && !crtc->state->active) { - spin_lock_irq(&crtc->dev->event_lock); drm_crtc_send_vblank_event(crtc, crtc->state->event); - spin_unlock_irq(&crtc->dev->event_lock); - crtc->state->event = NULL; } + spin_unlock_irq(&crtc->dev->event_lock); } static int exynos_crtc_atomic_check(struct drm_crtc *crtc, -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/3] CVE-2024-38598
by Li Nan 05 Jul '24

05 Jul '24

Li Nan (2): Revert "md/raid10: fix slab-out-of-bounds in md_bitmap_get_counter" md/raid10: check slab-out-of-bounds in md_bitmap_get_counter Yu Kuai (1): md: fix resync softlockup when bitmap size is less than array size drivers/md/md-bitmap.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) -- 2.39.2

2 4

[PATCH OLK-5.10 0/3] CVE-2024-38598
by Li Nan 05 Jul '24

05 Jul '24

Li Nan (2): Revert "md/raid10: fix slab-out-of-bounds in md_bitmap_get_counter" md/raid10: check slab-out-of-bounds in md_bitmap_get_counter Yu Kuai (1): md: fix resync softlockup when bitmap size is less than array size drivers/md/md-bitmap.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) -- 2.39.2

2 4

[OLK-6.6] usb-storage: alauda: Check whether the media is initialized
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Shichao Lai <shichaorai(a)gmail.com> mainline inclusion from mainline-v6.10-rc4 commit 16637fea001ab3c8df528a8995b3211906165a30 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6YQV CVE: CVE-2024-38619 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba(). - Add a member "media_initialized" to struct alauda_info. - Change a condition in alauda_check_media() to ensure the first initialization. - Add an error check for the return value of alauda_init_media(). Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support") Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Reviewed-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Shichao Lai <shichaorai(a)gmail.com> Link: https://lore.kernel.org/r/20240526012745.2852061-1-shichaorai@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/usb/storage/alauda.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c index 115f05a6201a..40d34cc28344 100644 --- a/drivers/usb/storage/alauda.c +++ b/drivers/usb/storage/alauda.c @@ -105,6 +105,8 @@ struct alauda_info { unsigned char sense_key; unsigned long sense_asc; /* additional sense code */ unsigned long sense_ascq; /* additional sense code qualifier */ + + bool media_initialized; }; #define short_pack(lsb,msb) ( ((u16)(lsb)) | ( ((u16)(msb))<<8 ) ) @@ -476,11 +478,12 @@ static int alauda_check_media(struct us_data *us) } /* Check for media change */ - if (status[0] & 0x08) { + if (status[0] & 0x08 || !info->media_initialized) { usb_stor_dbg(us, "Media change detected\n"); alauda_free_maps(&MEDIA_INFO(us)); - alauda_init_media(us); - + rc = alauda_init_media(us); + if (rc == USB_STOR_TRANSPORT_GOOD) + info->media_initialized = true; info->sense_key = UNIT_ATTENTION; info->sense_asc = 0x28; info->sense_ascq = 0x00; -- 2.25.1

1 0

[openEuler-22.03-LTS-SP1] ksmbd: fix wrong DataOffset validation of create context
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 17d5b135bb720832364e8f55f6a887a3c7ec8fdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAAVBH CVE: CVE-2023-4458 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ->DataOffset of create context is 0, DataBuffer size is not correctly validated. This patch change wrong validation code and consider tag length in request. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-21824 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/oplock.c fs/smb/server/oplock.c [oplock.c hasn't moved from fs/ksmbd to fs/smb/server.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/ksmbd/oplock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/oplock.c b/fs/ksmbd/oplock.c index fc5b2137002f..6df455a54b70 100644 --- a/fs/ksmbd/oplock.c +++ b/fs/ksmbd/oplock.c @@ -1488,7 +1488,7 @@ struct create_context *smb2_find_context_vals(void *open_req, const char *tag, i name_len < 4 || name_off + name_len > cc_len || (value_off & 0x7) != 0 || - (value_off && (value_off < name_off + name_len)) || + (value_len && value_off < name_off + (name_len < 8 ? 8 : name_len)) || ((u64)value_off + value_len > cc_len)) return ERR_PTR(-EINVAL); -- 2.25.1

1 0

[OLK-5.10] ksmbd: fix wrong DataOffset validation of create context
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 17d5b135bb720832364e8f55f6a887a3c7ec8fdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAAVBH CVE: CVE-2023-4458 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ->DataOffset of create context is 0, DataBuffer size is not correctly validated. This patch change wrong validation code and consider tag length in request. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-21824 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/oplock.c fs/smb/server/oplock.c [oplock.c hasn't moved from fs/ksmbd to fs/smb/server.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/ksmbd/oplock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/oplock.c b/fs/ksmbd/oplock.c index fc5b2137002f..6df455a54b70 100644 --- a/fs/ksmbd/oplock.c +++ b/fs/ksmbd/oplock.c @@ -1488,7 +1488,7 @@ struct create_context *smb2_find_context_vals(void *open_req, const char *tag, i name_len < 4 || name_off + name_len > cc_len || (value_off & 0x7) != 0 || - (value_off && (value_off < name_off + name_len)) || + (value_len && value_off < name_off + (name_len < 8 ? 8 : name_len)) || ((u64)value_off + value_len > cc_len)) return ERR_PTR(-EINVAL); -- 2.25.1

1 0

[PATCH OLK-6.6] usb-storage: alauda: Check whether the media is initialized
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Shichao Lai <shichaorai(a)gmail.com> mainline inclusion from mainline-v6.10-rc4 commit 16637fea001ab3c8df528a8995b3211906165a30 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6YQV CVE: CVE-2024-38619 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba(). - Add a member "media_initialized" to struct alauda_info. - Change a condition in alauda_check_media() to ensure the first initialization. - Add an error check for the return value of alauda_init_media(). Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support") Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Reviewed-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Shichao Lai <shichaorai(a)gmail.com> Link: https://lore.kernel.org/r/20240526012745.2852061-1-shichaorai@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/usb/storage/alauda.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c index 115f05a6201a..40d34cc28344 100644 --- a/drivers/usb/storage/alauda.c +++ b/drivers/usb/storage/alauda.c @@ -105,6 +105,8 @@ struct alauda_info { unsigned char sense_key; unsigned long sense_asc; /* additional sense code */ unsigned long sense_ascq; /* additional sense code qualifier */ + + bool media_initialized; }; #define short_pack(lsb,msb) ( ((u16)(lsb)) | ( ((u16)(msb))<<8 ) ) @@ -476,11 +478,12 @@ static int alauda_check_media(struct us_data *us) } /* Check for media change */ - if (status[0] & 0x08) { + if (status[0] & 0x08 || !info->media_initialized) { usb_stor_dbg(us, "Media change detected\n"); alauda_free_maps(&MEDIA_INFO(us)); - alauda_init_media(us); - + rc = alauda_init_media(us); + if (rc == USB_STOR_TRANSPORT_GOOD) + info->media_initialized = true; info->sense_key = UNIT_ATTENTION; info->sense_asc = 0x28; info->sense_ascq = 0x00; -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ksmbd: fix wrong DataOffset validation of create context
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 17d5b135bb720832364e8f55f6a887a3c7ec8fdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAAVBH CVE: CVE-2023-4458 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ->DataOffset of create context is 0, DataBuffer size is not correctly validated. This patch change wrong validation code and consider tag length in request. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-21824 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/oplock.c fs/smb/server/oplock.c [oplock.c hasn't moved from fs/ksmbd to fs/smb/server.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/ksmbd/oplock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/oplock.c b/fs/ksmbd/oplock.c index fc5b2137002f..6df455a54b70 100644 --- a/fs/ksmbd/oplock.c +++ b/fs/ksmbd/oplock.c @@ -1488,7 +1488,7 @@ struct create_context *smb2_find_context_vals(void *open_req, const char *tag, i name_len < 4 || name_off + name_len > cc_len || (value_off & 0x7) != 0 || - (value_off && (value_off < name_off + name_len)) || + (value_len && value_off < name_off + (name_len < 8 ? 8 : name_len)) || ((u64)value_off + value_len > cc_len)) return ERR_PTR(-EINVAL); -- 2.25.1

2 1

[PATCH OLK-5.10] ksmbd: fix wrong DataOffset validation of create context
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 17d5b135bb720832364e8f55f6a887a3c7ec8fdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAAVBH CVE: CVE-2023-4458 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ->DataOffset of create context is 0, DataBuffer size is not correctly validated. This patch change wrong validation code and consider tag length in request. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-21824 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/oplock.c fs/smb/server/oplock.c [oplock.c hasn't moved from fs/ksmbd to fs/smb/server.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/ksmbd/oplock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/oplock.c b/fs/ksmbd/oplock.c index fc5b2137002f..6df455a54b70 100644 --- a/fs/ksmbd/oplock.c +++ b/fs/ksmbd/oplock.c @@ -1488,7 +1488,7 @@ struct create_context *smb2_find_context_vals(void *open_req, const char *tag, i name_len < 4 || name_off + name_len > cc_len || (value_off & 0x7) != 0 || - (value_off && (value_off < name_off + name_len)) || + (value_len && value_off < name_off + (name_len < 8 ? 8 : name_len)) || ((u64)value_off + value_len > cc_len)) return ERR_PTR(-EINVAL); -- 2.25.1

2 1

[PATCH OLK-6.6 0/1] CVE-2024-39461
by Yongqiang Liu 05 Jul '24

05 Jul '24

Nathan Chancellor (1): clk: bcm: rpi: Assign ->num before accessing ->hws drivers/clk/bcm/clk-raspberrypi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-5.10 0/2] CVE-2024-23848
by Yongqiang Liu 05 Jul '24

05 Jul '24

Hans Verkuil (2): media: cec: cec-adap: always cancel work in cec_transmit_msg_fh media: cec: cec-api: add locking in cec_release() drivers/media/cec/core/cec-adap.c | 3 +-- drivers/media/cec/core/cec-api.c | 3 +++ 2 files changed, 4 insertions(+), 2 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-23848
by Yongqiang Liu 05 Jul '24

05 Jul '24

CVE-2024-23848 Hans Verkuil (2): media: cec: cec-adap: always cancel work in cec_transmit_msg_fh media: cec: cec-api: add locking in cec_release() drivers/media/cec/cec-adap.c | 3 +-- drivers/media/cec/cec-api.c | 3 +++ 2 files changed, 4 insertions(+), 2 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1] wifi: ar5523: enable proper endpoint verification
by Chen Zhongjin 05 Jul '24

05 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v5.10.219 commit ee25389df80138907bc9dcdf4a2be2067cde9a81 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SCR CVE: CVE-2024-38565 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Reported-and-tested-by: syzbot+1bc2c2afd44f820a669f(a)syzkaller.appspotmail.com Fixes: b7d572e1871d ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240408121425.29392-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/net/wireless/ath/ar5523/ar5523.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c index efe38b2c1df7..71c2bf8817dc 100644 --- a/drivers/net/wireless/ath/ar5523/ar5523.c +++ b/drivers/net/wireless/ath/ar5523/ar5523.c @@ -1590,6 +1590,20 @@ static int ar5523_probe(struct usb_interface *intf, struct ar5523 *ar; int error = -ENOMEM; + static const u8 bulk_ep_addr[] = { + AR5523_CMD_TX_PIPE | USB_DIR_OUT, + AR5523_DATA_TX_PIPE | USB_DIR_OUT, + AR5523_CMD_RX_PIPE | USB_DIR_IN, + AR5523_DATA_RX_PIPE | USB_DIR_IN, + 0}; + + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr)) { + dev_err(&dev->dev, + "Could not find all expected endpoints\n"); + error = -ENODEV; + goto out; + } + /* * Load firmware if the device requires it. This will return * -ENXIO on success and we'll get called back afer the usb -- 2.25.1

2 1

[PATCH OLK-6.6] mm/slub: Reduce memory consumption in extreme scenarios
by Liu Shixin 05 Jul '24

05 Jul '24

From: Chen Jun <chenjun102(a)huawei.com> mainline inclusion from mainline-v6.10-rc1 commit 9198ffbd2b494daae3a67cac1d59c3a2754e64cd category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAATAS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When kmalloc_node() is called without __GFP_THISNODE and the target node lacks sufficient memory, SLUB allocates a folio from a different node other than the requested node, instead of taking a partial slab from it. However, since the allocated folio does not belong to the requested node, on the following allocation it is deactivated and added to the partial slab list of the node it belongs to. This behavior can result in excessive memory usage when the requested node has insufficient memory, as SLUB will repeatedly allocate folios from other nodes without reusing the previously allocated ones. To prevent memory wastage, when a preferred node is indicated (not NUMA_NO_NODE) but without a prior __GFP_THISNODE constraint: 1) try to get a partial slab from target node only by having __GFP_THISNODE in pc.flags for get_partial() 2) if 1) failed, try to allocate a new slab from target node with GFP_NOWAIT | __GFP_THISNODE opportunistically. 3) if 2) failed, retry with original gfpflags which will allow get_partial() try partial lists of other nodes before potentially allocating new page from other nodes Without a preferred node, or with __GFP_THISNODE constraint, the behavior remains unchanged. On qemu with 4 numa nodes and each numa has 1G memory. Write a test ko to call kmalloc_node(196, GFP_KERNEL, 3) for (4 * 1024 + 4) * 1024 times. cat /proc/slabinfo shows: kmalloc-256 4200530 13519712 256 32 2 : tunables.. after this patch, cat /proc/slabinfo shows: kmalloc-256 4200558 4200768 256 32 2 : tunables.. Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- mm/slub.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index ee3e32cdb7fd..7fcd18261c1e 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2392,7 +2392,7 @@ static struct slab *get_partial(struct kmem_cache *s, int node, searchnode = numa_mem_id(); slab = get_partial_node(s, get_node(s, searchnode), pc); - if (slab || node != NUMA_NO_NODE) + if (slab || (node != NUMA_NO_NODE && (pc->flags & __GFP_THISNODE))) return slab; return get_any_partial(s, pc); @@ -3068,6 +3068,7 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, struct slab *slab; unsigned long flags; struct partial_context pc; + bool try_thisnode = true; stat(s, ALLOC_SLOWPATH); @@ -3194,6 +3195,21 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, new_objects: pc.flags = gfpflags; + /* + * When a preferred node is indicated but no __GFP_THISNODE + * + * 1) try to get a partial slab from target node only by having + * __GFP_THISNODE in pc.flags for get_partial() + * 2) if 1) failed, try to allocate a new slab from target node with + * GPF_NOWAIT | __GFP_THISNODE opportunistically + * 3) if 2) failed, retry with original gfpflags which will allow + * get_partial() try partial lists of other nodes before potentially + * allocating new page from other nodes + */ + if (unlikely(node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) + && try_thisnode)) + pc.flags = GFP_NOWAIT | __GFP_THISNODE; + pc.orig_size = orig_size; slab = get_partial(s, node, &pc); if (slab) { @@ -3215,10 +3231,15 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, } slub_put_cpu_ptr(s->cpu_slab); - slab = new_slab(s, gfpflags, node); + slab = new_slab(s, pc.flags, node); c = slub_get_cpu_ptr(s->cpu_slab); if (unlikely(!slab)) { + if (node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) + && try_thisnode) { + try_thisnode = false; + goto new_objects; + } slab_out_of_memory(s, gfpflags, node); return NULL; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 05 Jul '24

05 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index c9ba61413c98..9bad601c7fe8 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -412,7 +412,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -421,6 +420,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] btrfs: fix use-after-free after failure to create a snapshot
by Baokun Li 05 Jul '24

05 Jul '24

From: Filipe Manana <fdmanana(a)suse.com> mainline inclusion from mainline-v5.17-rc3 commit 28b21c558a3753171097193b6f6602a94169093a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72FO CVE: CVE-2022-48733 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfs_commit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots; 2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list; 3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free. This issue could actually be detected by smatch, which produced the following warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list So fix this by not having the snapshot creation ioctl directly add the pending snapshot to the transaction's list. Instead add the pending snapshot to the transaction handle, and then at btrfs_commit_transaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will result in a transaction abort, in which case the ioctl code can safely free the pending snapshot and no one can access it anymore. CC: stable(a)vger.kernel.org # 5.10+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Conflicts: fs/btrfs/ioctl.c fs/btrfs/transaction.c [Because commit 74e97958121a ("btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations") was merged before this commit and current commit d0c2f4fa555eh ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") has not been merged yet.] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/btrfs/ioctl.c | 5 +---- fs/btrfs/transaction.c | 24 ++++++++++++++++++++++++ fs/btrfs/transaction.h | 2 ++ 3 files changed, 27 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 3d96eef71e2b..ca0894de2ecd 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -868,10 +868,7 @@ static int create_snapshot(struct btrfs_root *root, struct inode *dir, btrfs_qgroup_convert_reserved_meta(root, qgroup_reserved); qgroup_reserved = 0; - spin_lock(&fs_info->trans_lock); - list_add(&pending_snapshot->list, - &trans->transaction->pending_snapshots); - spin_unlock(&fs_info->trans_lock); + trans->pending_snapshot = pending_snapshot; ret = btrfs_commit_transaction(trans); if (ret) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index eb9ab3d3a7b3..897ea85e04e4 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -2031,6 +2031,27 @@ static inline void btrfs_wait_delalloc_flush(struct btrfs_fs_info *fs_info) btrfs_wait_ordered_roots(fs_info, U64_MAX, 0, (u64)-1); } +/* + * Add a pending snapshot associated with the given transaction handle to the + * respective handle. This must be called after the transaction commit started + * and while holding fs_info->trans_lock. + * This serves to guarantee a caller of btrfs_commit_transaction() that it can + * safely free the pending snapshot pointer in case btrfs_commit_transaction() + * returns an error. + */ +static void add_pending_snapshot(struct btrfs_trans_handle *trans) +{ + struct btrfs_transaction *cur_trans = trans->transaction; + + if (!trans->pending_snapshot) + return; + + lockdep_assert_held(&trans->fs_info->trans_lock); + ASSERT(cur_trans->state >= TRANS_STATE_COMMIT_START); + + list_add(&trans->pending_snapshot->list, &cur_trans->pending_snapshots); +} + int btrfs_commit_transaction(struct btrfs_trans_handle *trans) { struct btrfs_fs_info *fs_info = trans->fs_info; @@ -2117,6 +2138,8 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) spin_lock(&fs_info->trans_lock); if (cur_trans->state >= TRANS_STATE_COMMIT_START) { + add_pending_snapshot(trans); + spin_unlock(&fs_info->trans_lock); refcount_inc(&cur_trans->use_count); ret = btrfs_end_transaction(trans); @@ -2199,6 +2222,7 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) * COMMIT_DOING so make sure to wait for num_writers to == 1 again. */ spin_lock(&fs_info->trans_lock); + add_pending_snapshot(trans); cur_trans->state = TRANS_STATE_COMMIT_DOING; spin_unlock(&fs_info->trans_lock); wait_event(cur_trans->writer_wait, diff --git a/fs/btrfs/transaction.h b/fs/btrfs/transaction.h index f73654d93fa0..eb26eb068fe8 100644 --- a/fs/btrfs/transaction.h +++ b/fs/btrfs/transaction.h @@ -122,6 +122,8 @@ struct btrfs_trans_handle { struct btrfs_transaction *transaction; struct btrfs_block_rsv *block_rsv; struct btrfs_block_rsv *orig_rsv; + /* Set by a task that wants to create a snapshot. */ + struct btrfs_pending_snapshot *pending_snapshot; refcount_t use_count; unsigned int type; /* -- 2.31.1

2 1

[PATCH OLK-5.10] btrfs: fix use-after-free after failure to create a snapshot
by Baokun Li 05 Jul '24

05 Jul '24

From: Filipe Manana <fdmanana(a)suse.com> mainline inclusion from mainline-v5.17-rc3 commit 28b21c558a3753171097193b6f6602a94169093a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72FO CVE: CVE-2022-48733 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfs_commit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots; 2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list; 3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free. This issue could actually be detected by smatch, which produced the following warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list So fix this by not having the snapshot creation ioctl directly add the pending snapshot to the transaction's list. Instead add the pending snapshot to the transaction handle, and then at btrfs_commit_transaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will result in a transaction abort, in which case the ioctl code can safely free the pending snapshot and no one can access it anymore. CC: stable(a)vger.kernel.org # 5.10+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Conflicts: fs/btrfs/ioctl.c fs/btrfs/transaction.c [Because commit 74e97958121a ("btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations") was merged before this commit and current commit d0c2f4fa555eh ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") has not been merged yet.] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/btrfs/ioctl.c | 5 +---- fs/btrfs/transaction.c | 24 ++++++++++++++++++++++++ fs/btrfs/transaction.h | 2 ++ 3 files changed, 27 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index f625c42f48a3..358b9a5937a4 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -868,10 +868,7 @@ static int create_snapshot(struct btrfs_root *root, struct inode *dir, btrfs_qgroup_convert_reserved_meta(root, qgroup_reserved); qgroup_reserved = 0; - spin_lock(&fs_info->trans_lock); - list_add(&pending_snapshot->list, - &trans->transaction->pending_snapshots); - spin_unlock(&fs_info->trans_lock); + trans->pending_snapshot = pending_snapshot; ret = btrfs_commit_transaction(trans); if (ret) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index 968f5b45062c..a73b400450ce 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -2038,6 +2038,27 @@ static inline void btrfs_wait_delalloc_flush(struct btrfs_fs_info *fs_info) btrfs_wait_ordered_roots(fs_info, U64_MAX, 0, (u64)-1); } +/* + * Add a pending snapshot associated with the given transaction handle to the + * respective handle. This must be called after the transaction commit started + * and while holding fs_info->trans_lock. + * This serves to guarantee a caller of btrfs_commit_transaction() that it can + * safely free the pending snapshot pointer in case btrfs_commit_transaction() + * returns an error. + */ +static void add_pending_snapshot(struct btrfs_trans_handle *trans) +{ + struct btrfs_transaction *cur_trans = trans->transaction; + + if (!trans->pending_snapshot) + return; + + lockdep_assert_held(&trans->fs_info->trans_lock); + ASSERT(cur_trans->state >= TRANS_STATE_COMMIT_START); + + list_add(&trans->pending_snapshot->list, &cur_trans->pending_snapshots); +} + int btrfs_commit_transaction(struct btrfs_trans_handle *trans) { struct btrfs_fs_info *fs_info = trans->fs_info; @@ -2124,6 +2145,8 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) spin_lock(&fs_info->trans_lock); if (cur_trans->state >= TRANS_STATE_COMMIT_START) { + add_pending_snapshot(trans); + spin_unlock(&fs_info->trans_lock); refcount_inc(&cur_trans->use_count); ret = btrfs_end_transaction(trans); @@ -2206,6 +2229,7 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) * COMMIT_DOING so make sure to wait for num_writers to == 1 again. */ spin_lock(&fs_info->trans_lock); + add_pending_snapshot(trans); cur_trans->state = TRANS_STATE_COMMIT_DOING; spin_unlock(&fs_info->trans_lock); wait_event(cur_trans->writer_wait, diff --git a/fs/btrfs/transaction.h b/fs/btrfs/transaction.h index f73654d93fa0..eb26eb068fe8 100644 --- a/fs/btrfs/transaction.h +++ b/fs/btrfs/transaction.h @@ -122,6 +122,8 @@ struct btrfs_trans_handle { struct btrfs_transaction *transaction; struct btrfs_block_rsv *block_rsv; struct btrfs_block_rsv *orig_rsv; + /* Set by a task that wants to create a snapshot. */ + struct btrfs_pending_snapshot *pending_snapshot; refcount_t use_count; unsigned int type; /* -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/7] Sync bugfix from OLK-5.10
by Zheng Yejian 05 Jul '24

05 Jul '24

Daniel Borkmann (1): bpf: Fix __reg_bound_offset 64->32 var_off subreg propagation Krister Johansen (1): bpf: ensure main program has an extable Kumar Kartikeya Dwivedi (1): bpf: Clobber stack slot when writing over spilled PTR_TO_BTF_ID Martin KaFai Lau (1): bpf: Check the other end of slot_type for STACK_SPILL Stanislav Fomichev (2): bpf: Don't EFAULT for getsockopt with optval=NULL bpf: Don't EFAULT for {g,s}setsockopt with wrong optlen Wang Yufen (1): bpf: Fix memory leaks in __check_func_call kernel/bpf/cgroup.c | 24 +++++++- kernel/bpf/verifier.c | 61 ++++++++++++------- .../testing/selftests/bpf/prog_tests/align.c | 4 +- 3 files changed, 61 insertions(+), 28 deletions(-) -- 2.25.1

2 8

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 1b4ca2a2c1253c9e2d2428cc4fae541fdf3b326d
by kernel test robot 05 Jul '24

05 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 1b4ca2a2c1253c9e2d2428cc4fae541fdf3b326d !9765 i40e: Fix queues reservation for XDP Unverified Warning (likely false positive, please contact us if interested): drivers/uio/uio_hv_generic.c:311 hv_uio_probe() warn: 'pdata->recv_buf' double freed drivers/uio/uio_hv_generic.c:311 hv_uio_probe() warn: 'pdata->send_buf' double freed Warning ids grouped by kconfigs: recent_errors `-- x86_64-randconfig-161-20240704 |-- drivers-uio-uio_hv_generic.c-hv_uio_probe()-warn:pdata-recv_buf-double-freed `-- drivers-uio-uio_hv_generic.c-hv_uio_probe()-warn:pdata-send_buf-double-freed elapsed time: 734m configs tested: 34 configs skipped: 128 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc-13.2.0 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 gcc-13.2.0 arm64 randconfig-002-20240705 gcc-13.2.0 arm64 randconfig-003-20240705 gcc-13.2.0 arm64 randconfig-004-20240705 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6] BUILD SUCCESS b206e4b36a7f6d4d7806d653f1e71867dd56571d
by kernel test robot 05 Jul '24

05 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: b206e4b36a7f6d4d7806d653f1e71867dd56571d !9757 net: openvswitch: fix overwriting ct original tuple for ICMPv6 Warning ids grouped by kconfigs: recent_errors `-- arm64-allmodconfig `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag elapsed time: 723m configs tested: 21 configs skipped: 124 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 clang-19 arm64 randconfig-002-20240705 clang-19 arm64 randconfig-003-20240705 clang-19 arm64 randconfig-004-20240705 clang-19 loongarch allmodconfig gcc-13.2.0 loongarch allnoconfig gcc-13.2.0 loongarch randconfig-001-20240705 gcc-13.2.0 loongarch randconfig-002-20240705 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 0/2] Add a switch to enable hungtask check for io
by Li Lingfeng 05 Jul '24

05 Jul '24

Add a switch to enable hungtask check for io Li Lingfeng (1): block: disable BLK_IO_HUNG_TASK_CHECK by default Yu Kuai (1): block: add a switch to enable hungtask check for io arch/arm64/configs/openeuler_defconfig | 1 + arch/x86/configs/openeuler_defconfig | 1 + block/Kconfig | 9 +++++++++ block/bio.c | 2 +- block/blk-core.c | 13 ++++++++++++- block/blk-mq.c | 2 +- block/blk.h | 1 + 7 files changed, 26 insertions(+), 3 deletions(-) -- 2.31.1

2 3

[PATCH openEuler-22.03-LTS-SP1] iomap: Don't finish dio under irq when there exists pages
by Zhihao Cheng 05 Jul '24

05 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA4DAW CVE: NA -------------------------------- Since commit 6fac6d0e975afe1dec ("ext4: Optimize endio process for DIO overwrites"), pages invalidating won't be done in io completeing process, which could make generic/451 failed. In generic 451, there are two concurrent tasks: task A is reading(with page cache) a file, task B is directly writing and reading to verify content. Task B will verify failed in following process: task A task B direct_write(offs=L, content_Y) submit_IO content_X = read_page(offs=L) // stale data, because IO is not completed content_X = find_page(offs=L) // content_Y != content_X Fixes: 6fac6d0e975a ("ext4: Optimize endio process for DIO overwrites") Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/iomap/direct-io.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index ad12ffcc5085..4760a481e444 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -180,6 +180,11 @@ static void iomap_dio_bio_end_io(struct bio *bio) goto release_bio; } + if ((dio->flags & IOMAP_DIO_INLINE_COMP) && dio->size && + (dio->flags & IOMAP_DIO_WRITE) && + file_inode(iocb->ki_filp)->i_mapping->nrpages) + dio->flags &= ~IOMAP_DIO_INLINE_COMP; + /* * Flagged with IOMAP_DIO_INLINE_COMP, we can complete it inline */ -- 2.31.1

2 1

[PATCH OLK-5.10] iomap: Don't finish dio under irq when there exists pages
by Zhihao Cheng 05 Jul '24

05 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA4DAW CVE: NA -------------------------------- Since commit 48774b90b5677bdb4 ("ext4: Optimize endio process for DIO overwrites"), pages invalidating won't be done in io completeing process, which could make generic/451 failed. In generic 451, there are two concurrent tasks: task A is reading(with page cache) a file, task B is directly writing and reading to verify content. Task B will verify failed in following process: task A task B direct_write(offs=L, content_Y) submit_IO content_X = read_page(offs=L) // stale data, because IO is not completed content_X = find_page(offs=L) // content_Y != content_X Fixes: 48774b90b567 ("ext4: Optimize endio process for DIO overwrites") Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/iomap/direct-io.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index 61cc9a13a40a..fc9908d79f93 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -180,6 +180,11 @@ static void iomap_dio_bio_end_io(struct bio *bio) goto release_bio; } + if ((dio->flags & IOMAP_DIO_INLINE_COMP) && dio->size && + (dio->flags & IOMAP_DIO_WRITE) && + file_inode(iocb->ki_filp)->i_mapping->nrpages) + dio->flags &= ~IOMAP_DIO_INLINE_COMP; + /* * Flagged with IOMAP_DIO_INLINE_COMP, we can complete it inline */ -- 2.31.1

2 1

[openeuler:OLK-5.10] BUILD SUCCESS 451734a9a63432990e3124ae33b413c8bb221f5a
by kernel test robot 05 Jul '24

05 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 451734a9a63432990e3124ae33b413c8bb221f5a !9716 ax25: Fix reference count leak issues of ax25_dev Warning ids grouped by kconfigs: recent_errors `-- x86_64-allnoconfig `-- drivers-arm-spe-spe.c:linux-perf-arm_pmu.h-is-included-more-than-once. elapsed time: 725m configs tested: 34 configs skipped: 128 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 clang-19 arm64 randconfig-002-20240705 clang-19 arm64 randconfig-003-20240705 clang-19 arm64 randconfig-004-20240705 clang-19 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-22.03-LTS-SP1] f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
by Baokun Li 04 Jul '24

04 Jul '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v5.10.219 commit a6e1f7744e9b84f86a629a76024bba8468aa153b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YN0 CVE: CVE-2024-34027 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0a4ed2d97cb6d044196cc3e726b6699222b41019 ] It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case. Fixes: ef8d563f184e ("f2fs: introduce F2FS_IOC_RELEASE_COMPRESS_BLOCKS") Fixes: c75488fb4d82 ("f2fs: introduce F2FS_IOC_RESERVE_COMPRESS_BLOCKS") Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/f2fs/file.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 38510a24861d..ab708374d88e 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -3572,9 +3572,12 @@ static int f2fs_release_compress_blocks(struct file *filp, unsigned long arg) struct dnode_of_data dn; pgoff_t end_offset, count; + f2fs_lock_op(sbi); + set_new_dnode(&dn, inode, NULL, NULL, 0); ret = f2fs_get_dnode_of_data(&dn, page_idx, LOOKUP_NODE); if (ret) { + f2fs_unlock_op(sbi); if (ret == -ENOENT) { page_idx = f2fs_get_next_page_offset(&dn, page_idx); @@ -3592,6 +3595,8 @@ static int f2fs_release_compress_blocks(struct file *filp, unsigned long arg) f2fs_put_dnode(&dn); + f2fs_unlock_op(sbi); + if (ret < 0) break; @@ -3725,9 +3730,12 @@ static int f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg) struct dnode_of_data dn; pgoff_t end_offset, count; + f2fs_lock_op(sbi); + set_new_dnode(&dn, inode, NULL, NULL, 0); ret = f2fs_get_dnode_of_data(&dn, page_idx, LOOKUP_NODE); if (ret) { + f2fs_unlock_op(sbi); if (ret == -ENOENT) { page_idx = f2fs_get_next_page_offset(&dn, page_idx); @@ -3745,6 +3753,8 @@ static int f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg) f2fs_put_dnode(&dn); + f2fs_unlock_op(sbi); + if (ret < 0) break; -- 2.31.1

2 1

[PATCH OLK-5.10] f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
by Baokun Li 04 Jul '24

04 Jul '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v5.10.219 commit a6e1f7744e9b84f86a629a76024bba8468aa153b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YN0 CVE: CVE-2024-34027 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0a4ed2d97cb6d044196cc3e726b6699222b41019 ] It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case. Fixes: ef8d563f184e ("f2fs: introduce F2FS_IOC_RELEASE_COMPRESS_BLOCKS") Fixes: c75488fb4d82 ("f2fs: introduce F2FS_IOC_RESERVE_COMPRESS_BLOCKS") Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/f2fs/file.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 01995d1b2437..eff0b359f1a3 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -3579,9 +3579,12 @@ static int f2fs_release_compress_blocks(struct file *filp, unsigned long arg) struct dnode_of_data dn; pgoff_t end_offset, count; + f2fs_lock_op(sbi); + set_new_dnode(&dn, inode, NULL, NULL, 0); ret = f2fs_get_dnode_of_data(&dn, page_idx, LOOKUP_NODE); if (ret) { + f2fs_unlock_op(sbi); if (ret == -ENOENT) { page_idx = f2fs_get_next_page_offset(&dn, page_idx); @@ -3599,6 +3602,8 @@ static int f2fs_release_compress_blocks(struct file *filp, unsigned long arg) f2fs_put_dnode(&dn); + f2fs_unlock_op(sbi); + if (ret < 0) break; @@ -3732,9 +3737,12 @@ static int f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg) struct dnode_of_data dn; pgoff_t end_offset, count; + f2fs_lock_op(sbi); + set_new_dnode(&dn, inode, NULL, NULL, 0); ret = f2fs_get_dnode_of_data(&dn, page_idx, LOOKUP_NODE); if (ret) { + f2fs_unlock_op(sbi); if (ret == -ENOENT) { page_idx = f2fs_get_next_page_offset(&dn, page_idx); @@ -3752,6 +3760,8 @@ static int f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg) f2fs_put_dnode(&dn); + f2fs_unlock_op(sbi); + if (ret < 0) break; -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] i40e: Fix queues reservation for XDP
by Zeng Heng 04 Jul '24

04 Jul '24

From: Sylwester Dziedziuch <sylwesterx.dziedziuch(a)intel.com> stable inclusion from stable-v4.19.228 commit d46fa4ea9756ef6cbcf9752d0832cc66e2d7121b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72DT CVE: CVE-2021-47619 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 92947844b8beee988c0ce17082b705c2f75f0742 upstream. When XDP was configured on a system with large number of CPUs and X722 NIC there was a call trace with NULL pointer dereference. i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12 i40e 0000:87:00.0: setup of MAIN VSI failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e] Call Trace: ? i40e_reconfig_rss_queues+0x130/0x130 [i40e] dev_xdp_install+0x61/0xe0 dev_xdp_attach+0x18a/0x4c0 dev_change_xdp_fd+0x1e6/0x220 do_setlink+0x616/0x1030 ? ahci_port_stop+0x80/0x80 ? ata_qc_issue+0x107/0x1e0 ? lock_timer_base+0x61/0x80 ? __mod_timer+0x202/0x380 rtnl_setlink+0xe5/0x170 ? bpf_lsm_binder_transaction+0x10/0x10 ? security_capable+0x36/0x50 rtnetlink_rcv_msg+0x121/0x350 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x50/0xf0 netlink_unicast+0x1d3/0x2a0 netlink_sendmsg+0x22a/0x440 sock_sendmsg+0x5e/0x60 __sys_sendto+0xf0/0x160 ? __sys_getsockname+0x7e/0xc0 ? _copy_from_user+0x3c/0x80 ? __sys_setsockopt+0xc8/0x1a0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f83fa7a39e0 This was caused by PF queue pile fragmentation due to flow director VSI queue being placed right after main VSI. Because of this main VSI was not able to resize its queue allocation for XDP resulting in no queues allocated for main VSI when XDP was turned on. Fix this by always allocating last queue in PF queue pile for a flow director VSI. Fixes: 41c445ff0f48 ("i40e: main driver core") Fixes: 74608d17fe29 ("i40e: add support for XDP_TX action") Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch(a)intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski(a)intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski(a)intel.com> Tested-by: Kiran Bhandare <kiranx.bhandare(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/net/ethernet/intel/i40e/i40e_main.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index 74cf22982f59..bfa5e286c489 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -193,6 +193,20 @@ static int i40e_get_lump(struct i40e_pf *pf, struct i40e_lump_tracking *pile, return -EINVAL; } + /* Allocate last queue in the pile for FDIR VSI queue + * so it doesn't fragment the qp_pile + */ + if (pile == pf->qp_pile && pf->vsi[id]->type == I40E_VSI_FDIR) { + if (pile->list[pile->num_entries - 1] & I40E_PILE_VALID_BIT) { + dev_err(&pf->pdev->dev, + "Cannot allocate queue %d for I40E_VSI_FDIR\n", + pile->num_entries - 1); + return -ENOMEM; + } + pile->list[pile->num_entries - 1] = id | I40E_PILE_VALID_BIT; + return pile->num_entries - 1; + } + /* start the linear search with an imperfect hint */ i = pile->search_hint; while (i < pile->num_entries) { -- 2.25.1

2 1

[PATCH OLK-5.10] wifi: ar5523: enable proper endpoint verification
by Chen Zhongjin 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v5.10.219 commit ee25389df80138907bc9dcdf4a2be2067cde9a81 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SCR CVE: CVE-2024-38565 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Reported-and-tested-by: syzbot+1bc2c2afd44f820a669f(a)syzkaller.appspotmail.com Fixes: b7d572e1871d ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240408121425.29392-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/net/wireless/ath/ar5523/ar5523.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c index efe38b2c1df7..71c2bf8817dc 100644 --- a/drivers/net/wireless/ath/ar5523/ar5523.c +++ b/drivers/net/wireless/ath/ar5523/ar5523.c @@ -1590,6 +1590,20 @@ static int ar5523_probe(struct usb_interface *intf, struct ar5523 *ar; int error = -ENOMEM; + static const u8 bulk_ep_addr[] = { + AR5523_CMD_TX_PIPE | USB_DIR_OUT, + AR5523_DATA_TX_PIPE | USB_DIR_OUT, + AR5523_CMD_RX_PIPE | USB_DIR_IN, + AR5523_DATA_RX_PIPE | USB_DIR_IN, + 0}; + + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr)) { + dev_err(&dev->dev, + "Could not find all expected endpoints\n"); + error = -ENODEV; + goto out; + } + /* * Load firmware if the device requires it. This will return * -ENXIO on success and we'll get called back afer the usb -- 2.25.1

2 1

[PATCH OLK-6.6 0/2] Fix xfs file creation issue
by Zizhi Wo 04 Jul '24

04 Jul '24

Revert the previous fix patch and adapt to the latest repair solution. Zizhi Wo (2): Revert "xfs: Fix file creation failure" xfs: Avoid races with cnt_btree lastrec updates fs/xfs/libxfs/xfs_alloc.c | 125 +++++++++++++++++++++++++++++--- fs/xfs/libxfs/xfs_alloc_btree.c | 72 ------------------ fs/xfs/libxfs/xfs_btree.c | 51 ------------- fs/xfs/libxfs/xfs_btree.h | 19 +---- 4 files changed, 115 insertions(+), 152 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-26816
by liwei 04 Jul '24

04 Jul '24

CVE-2024-26816 Guixiong Wei (1): x86/boot: Ignore relocations in .notes sections in walk_relocs() too Kees Cook (1): x86, relocs: Ignore relocations in .notes section arch/x86/tools/relocs.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.25.1

2 3

[PATCH OLK-5.10 0/2] CVE-2024-26816
by liwei 04 Jul '24

04 Jul '24

CVE-2024-26816 Guixiong Wei (1): x86/boot: Ignore relocations in .notes sections in walk_relocs() too Kees Cook (1): x86, relocs: Ignore relocations in .notes section arch/x86/tools/relocs.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-26816
by liwei 04 Jul '24

04 Jul '24

CVE-2024-26816 Guixiong Wei (1): x86/boot: Ignore relocations in .notes sections in walk_relocs() too Kees Cook (1): x86, relocs: Ignore relocations in .notes section arch/x86/tools/relocs.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/3] CVE-2024-23848
by Yongqiang Liu 04 Jul '24

04 Jul '24

Hans Verkuil (3): media: cec: cec-adap: always cancel work in cec_transmit_msg_fh media: cec: cec-api: add locking in cec_release() media: cec: core: avoid recursive cec_claim_log_addrs drivers/media/cec/cec-adap.c | 9 ++++++--- drivers/media/cec/cec-api.c | 5 ++++- include/media/cec.h | 1 + 3 files changed, 11 insertions(+), 4 deletions(-) -- 2.34.1

2 4

[PATCH v2 OLK-5.10] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> mainline inclusion from mainline-v6.9-rc1 commit aaa8736370db1a78f0e8434344a484f9fd20be3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 1c3a1962cade..0043fd374a62 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -596,6 +596,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-6.6] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 04 Jul '24

04 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index 33b21a0c0548..8a848ce72e29 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -561,7 +561,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -570,6 +569,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH OLK-5.10] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 04 Jul '24

04 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index c9ba61413c98..9bad601c7fe8 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -412,7 +412,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -421,6 +420,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] wifi: ar5523: enable proper endpoint verification
by Chen Zhongjin 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v4.19.316 commit 79ddf5f2020fd593d50f1363bb5131283d74f78f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SCR CVE: CVE-2024-38565 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Reported-and-tested-by: syzbot+1bc2c2afd44f820a669f(a)syzkaller.appspotmail.com Fixes: b7d572e1871d ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240408121425.29392-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/net/wireless/ath/ar5523/ar5523.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c index da2d179430ca..91b524ca3243 100644 --- a/drivers/net/wireless/ath/ar5523/ar5523.c +++ b/drivers/net/wireless/ath/ar5523/ar5523.c @@ -1580,6 +1580,20 @@ static int ar5523_probe(struct usb_interface *intf, struct ar5523 *ar; int error = -ENOMEM; + static const u8 bulk_ep_addr[] = { + AR5523_CMD_TX_PIPE | USB_DIR_OUT, + AR5523_DATA_TX_PIPE | USB_DIR_OUT, + AR5523_CMD_RX_PIPE | USB_DIR_IN, + AR5523_DATA_RX_PIPE | USB_DIR_IN, + 0}; + + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr)) { + dev_err(&dev->dev, + "Could not find all expected endpoints\n"); + error = -ENODEV; + goto out; + } + /* * Load firmware if the device requires it. This will return * -ENXIO on success and we'll get called back afer the usb -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 04 Jul '24

04 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index 56b8e7167790..857b1ffe3d85 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -427,7 +427,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -436,6 +435,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH v2 OLK-5.10] arm64: arm_pmuv3: Correctly extract and check the PMUVer
by Junhao He 04 Jul '24

04 Jul '24

mainline inclusion from mainline-v6.10-rc1 commit b782e8d07baac95a5ce3f8773cc61f4ed7d0ccbc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9J01A CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------------- Currently we're using "sbfx" to extract the PMUVer from ID_AA64DFR0_EL1 and skip the init/reset if no PMU present when the extracted PMUVer is negative or is zero. However for PMUv3p8 the PMUVer will be 0b1000 and PMUVer extracted by "sbfx" will always be negative and we'll skip the init/reset in __init_el2_debug/reset_pmuserenr_el0 unexpectedly. So this patch use "ubfx" instead of "sbfx" to extract the PMUVer. If the PMUVer is implementation defined (0b1111) or not implemented(0b0000) then skip the reset/init. Previously we'll also skip the init/reset if the PMUVer is higher than the version we known (currently PMUv3p9), with this patch we'll only skip if the PMU is not implemented or implementation defined. This keeps consistence with how we probe the PMU in the driver with pmuv3_implemented(). Signed-off-by: Yicong Yang <yangyicong(a)hisilicon.com> Link: https://lore.kernel.org/r/20240411123030.7201-1-yangyicong@huawei.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> --- arch/arm64/include/asm/assembler.h | 7 ++++--- arch/arm64/include/asm/sysreg.h | 1 + arch/arm64/kernel/head.S | 9 +++++---- 3 files changed, 10 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h index 5e6bacda05d8..63db8e5ec9f8 100644 --- a/arch/arm64/include/asm/assembler.h +++ b/arch/arm64/include/asm/assembler.h @@ -466,9 +466,10 @@ USER(\label, ic ivau, \tmp2) // invalidate I line PoU */ .macro reset_pmuserenr_el0, tmpreg mrs \tmpreg, id_aa64dfr0_el1 - sbfx \tmpreg, \tmpreg, #ID_AA64DFR0_PMUVER_SHIFT, #4 - cmp \tmpreg, #1 // Skip if no PMU present - b.lt 9000f + ubfx \tmpreg, \tmpreg, #ID_AA64DFR0_PMUVER_SHIFT, #4 + cmp \tmpreg, #ID_AA64DFR0_PMUVER_NI + ccmp \tmpreg, #ID_AA64DFR0_PMUVER_IMP_DEF, #4, ne + b.eq 9000f msr pmuserenr_el0, xzr // Disable PMU access from EL0 9000: .endm diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h index 8bcc9ac9963e..9705f7abd428 100644 --- a/arch/arm64/include/asm/sysreg.h +++ b/arch/arm64/include/asm/sysreg.h @@ -1488,6 +1488,7 @@ #define ID_AA64DFR0_EL1_BRBE_NI 0x0 #define ID_AA64DFR0_EL1_BRBE_IMP 0x1 #define ID_AA64DFR0_EL1_BRBE_BRBE_V1P1 0x2 +#define ID_AA64DFR0_PMUVER_NI 0x0 #define ID_AA64DFR0_PMUVER_8_0 0x1 #define ID_AA64DFR0_PMUVER_8_1 0x4 #define ID_AA64DFR0_PMUVER_8_4 0x5 diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 91890de6cefa..b44213388bab 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -623,13 +623,14 @@ set_hcr: /* EL2 debug */ mrs x1, id_aa64dfr0_el1 - sbfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 - cmp x0, #1 - b.lt 4f // Skip if no PMU present + ubfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 + cmp x0, #ID_AA64DFR0_PMUVER_NI + ccmp x0, #ID_AA64DFR0_PMUVER_IMP_DEF, #4, ne + b.eq 4f // Skip if no PMU present mrs x0, pmcr_el0 // Disable debug access traps ubfx x0, x0, #11, #5 // to EL2 and allow access to 4: - csel x3, xzr, x0, lt // all PMU counters from EL1 + csel x3, xzr, x0, eq // all PMU counters from EL1 /* Statistical profiling */ ubfx x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4 -- 2.33.0

2 1

[PATCH openEuler-22.03-LTS-SP1] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> mainline inclusion from mainline-v6.9-rc1 commit aaa8736370db1a78f0e8434344a484f9fd20be3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 1c3a1962cade..0043fd374a62 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -596,6 +596,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-5.10] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> mainline inclusion from mainline-v6.9-rc1 commit aaa8736370db1a78f0e8434344a484f9fd20be3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 3a6c8ebc8032..4fe8eab9152f 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -579,6 +579,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-5.10] arm64: arm_pmuv3: Correctly extract and check the PMUVer
by Junhao He 04 Jul '24

04 Jul '24

mainline inclusion from mainline-v6.10-rc1 commit b782e8d07baac95a5ce3f8773cc61f4ed7d0ccbc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9GLIG CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------------- Currently we're using "sbfx" to extract the PMUVer from ID_AA64DFR0_EL1 and skip the init/reset if no PMU present when the extracted PMUVer is negative or is zero. However for PMUv3p8 the PMUVer will be 0b1000 and PMUVer extracted by "sbfx" will always be negative and we'll skip the init/reset in __init_el2_debug/reset_pmuserenr_el0 unexpectedly. So this patch use "ubfx" instead of "sbfx" to extract the PMUVer. If the PMUVer is implementation defined (0b1111) or not implemented(0b0000) then skip the reset/init. Previously we'll also skip the init/reset if the PMUVer is higher than the version we known (currently PMUv3p9), with this patch we'll only skip if the PMU is not implemented or implementation defined. This keeps consistence with how we probe the PMU in the driver with pmuv3_implemented(). Signed-off-by: Yicong Yang <yangyicong(a)hisilicon.com> Link: https://lore.kernel.org/r/20240411123030.7201-1-yangyicong@huawei.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> --- arch/arm64/include/asm/assembler.h | 7 ++++--- arch/arm64/include/asm/sysreg.h | 1 + arch/arm64/kernel/head.S | 9 +++++---- 3 files changed, 10 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h index 5e6bacda05d8..63db8e5ec9f8 100644 --- a/arch/arm64/include/asm/assembler.h +++ b/arch/arm64/include/asm/assembler.h @@ -466,9 +466,10 @@ USER(\label, ic ivau, \tmp2) // invalidate I line PoU */ .macro reset_pmuserenr_el0, tmpreg mrs \tmpreg, id_aa64dfr0_el1 - sbfx \tmpreg, \tmpreg, #ID_AA64DFR0_PMUVER_SHIFT, #4 - cmp \tmpreg, #1 // Skip if no PMU present - b.lt 9000f + ubfx \tmpreg, \tmpreg, #ID_AA64DFR0_PMUVER_SHIFT, #4 + cmp \tmpreg, #ID_AA64DFR0_PMUVER_NI + ccmp \tmpreg, #ID_AA64DFR0_PMUVER_IMP_DEF, #4, ne + b.eq 9000f msr pmuserenr_el0, xzr // Disable PMU access from EL0 9000: .endm diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h index 8bcc9ac9963e..9705f7abd428 100644 --- a/arch/arm64/include/asm/sysreg.h +++ b/arch/arm64/include/asm/sysreg.h @@ -1488,6 +1488,7 @@ #define ID_AA64DFR0_EL1_BRBE_NI 0x0 #define ID_AA64DFR0_EL1_BRBE_IMP 0x1 #define ID_AA64DFR0_EL1_BRBE_BRBE_V1P1 0x2 +#define ID_AA64DFR0_PMUVER_NI 0x0 #define ID_AA64DFR0_PMUVER_8_0 0x1 #define ID_AA64DFR0_PMUVER_8_1 0x4 #define ID_AA64DFR0_PMUVER_8_4 0x5 diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 91890de6cefa..b44213388bab 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -623,13 +623,14 @@ set_hcr: /* EL2 debug */ mrs x1, id_aa64dfr0_el1 - sbfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 - cmp x0, #1 - b.lt 4f // Skip if no PMU present + ubfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 + cmp x0, #ID_AA64DFR0_PMUVER_NI + ccmp x0, #ID_AA64DFR0_PMUVER_IMP_DEF, #4, ne + b.eq 4f // Skip if no PMU present mrs x0, pmcr_el0 // Disable debug access traps ubfx x0, x0, #11, #5 // to EL2 and allow access to 4: - csel x3, xzr, x0, lt // all PMU counters from EL1 + csel x3, xzr, x0, eq // all PMU counters from EL1 /* Statistical profiling */ ubfx x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4 -- 2.33.0

2 1

[PATCH openEuler-1.0-LTS] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> stable inclusion from stable-v4.19.311 commit 13edb509abc91c72152a11baaf0e7c060a312e03 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit aaa8736370db1a78f0e8434344a484f9fd20be3b ] When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 3a6c8ebc8032..4fe8eab9152f 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -579,6 +579,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-6.6] cxl/pci: Skip to handle RAS errors if CXL.mem device is detached
by Wei Li 04 Jul '24

04 Jul '24

From: Li Ming <ming4.li(a)intel.com> mainline inclusion from mainline-v6.8-rc6 commit eef5c7b28dbecd6b141987a96db6c54e49828102 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2M3 CVE: CVE-2024-26762 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i… -------------------------------- The PCI AER model is an awkward fit for CXL error handling. While the expectation is that a PCI device can escalate to link reset to recover from an AER event, the same reset on CXL amounts to a surprise memory hotplug of massive amounts of memory. At present, the CXL error handler attempts some optimistic error handling to unbind the device from the cxl_mem driver after reaping some RAS register values. This results in a "hopeful" attempt to unplug the memory, but there is no guarantee that will succeed. A subsequent AER notification after the memdev unbind event can no longer assume the registers are mapped. Check for memdev bind before reaping status register values to avoid crashes of the form: BUG: unable to handle page fault for address: ffa00000195e9100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] RIP: 0010:__cxl_handle_ras+0x30/0x110 [cxl_core] [...] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x160 ? kernelmode_fixup_or_oops+0x84/0x110 ? exc_page_fault+0x113/0x170 ? asm_exc_page_fault+0x26/0x30 ? __pfx_dpc_reset_link+0x10/0x10 ? __cxl_handle_ras+0x30/0x110 [cxl_core] ? find_cxl_port+0x59/0x80 [cxl_core] cxl_handle_rp_ras+0xbc/0xd0 [cxl_core] cxl_error_detected+0x6c/0xf0 [cxl_core] report_error_detected+0xc7/0x1c0 pci_walk_bus+0x73/0x90 pcie_do_recovery+0x23f/0x330 Longer term, the unbind and PCI_ERS_RESULT_DISCONNECT behavior might need to be replaced with a new PCI_ERS_RESULT_PANIC. Fixes: 6ac07883dbb5 ("cxl/pci: Add RCH downstream port error logging") Cc: stable(a)vger.kernel.org Suggested-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Li Ming <ming4.li(a)intel.com> Link: https://lore.kernel.org/r/20240129131856.2458980-1-ming4.li@intel.com Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Wei Li <liwei391(a)huawei.com> --- drivers/cxl/core/pci.c | 43 ++++++++++++++++++++++++++++++------------ 1 file changed, 31 insertions(+), 12 deletions(-) diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c index 011197fa61036..e78c8e6a5c9a7 100644 --- a/drivers/cxl/core/pci.c +++ b/drivers/cxl/core/pci.c @@ -904,11 +904,21 @@ static void cxl_handle_rdport_errors(struct cxl_dev_state *cxlds) { } void cxl_cor_error_detected(struct pci_dev *pdev) { struct cxl_dev_state *cxlds = pci_get_drvdata(pdev); + struct device *dev = &cxlds->cxlmd->dev; + + scoped_guard(device, dev) { + if (!dev->driver) { + dev_warn(&pdev->dev, + "%s: memdev disabled, abort error handling\n", + dev_name(dev)); + return; + } - if (cxlds->rcd) - cxl_handle_rdport_errors(cxlds); + if (cxlds->rcd) + cxl_handle_rdport_errors(cxlds); - cxl_handle_endpoint_cor_ras(cxlds); + cxl_handle_endpoint_cor_ras(cxlds); + } } EXPORT_SYMBOL_NS_GPL(cxl_cor_error_detected, CXL); @@ -920,16 +930,25 @@ pci_ers_result_t cxl_error_detected(struct pci_dev *pdev, struct device *dev = &cxlmd->dev; bool ue; - if (cxlds->rcd) - cxl_handle_rdport_errors(cxlds); + scoped_guard(device, dev) { + if (!dev->driver) { + dev_warn(&pdev->dev, + "%s: memdev disabled, abort error handling\n", + dev_name(dev)); + return PCI_ERS_RESULT_DISCONNECT; + } + + if (cxlds->rcd) + cxl_handle_rdport_errors(cxlds); + /* + * A frozen channel indicates an impending reset which is fatal to + * CXL.mem operation, and will likely crash the system. On the off + * chance the situation is recoverable dump the status of the RAS + * capability registers and bounce the active state of the memdev. + */ + ue = cxl_handle_endpoint_ras(cxlds); + } - /* - * A frozen channel indicates an impending reset which is fatal to - * CXL.mem operation, and will likely crash the system. On the off - * chance the situation is recoverable dump the status of the RAS - * capability registers and bounce the active state of the memdev. - */ - ue = cxl_handle_endpoint_ras(cxlds); switch (state) { case pci_channel_io_normal: -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-39469
by Yu Liao 04 Jul '24

04 Jul '24

CVE-2024-39469 Matthew Wilcox (Oracle) (1): nilfs2: return the mapped address from nilfs_get_page() Ryusuke Konishi (1): nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors fs/nilfs2/dir.c | 59 +++++++++++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 31 deletions(-) -- 2.33.0

2 3

[PATCH v2 OLK-6.6] Revert "ACPI: processor: Add support for processors described as container packages"
by liwei 04 Jul '24

04 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAJ94 ---------------------------- 'processor_container_handler' identifies ACPI0010 does not match the Processor information reported by DSDT. This reverts commit 2f257a8ec840ccc5fcefab424f468552da7b15ff. Fixes: 2f257a8ec840 ("ACPI: processor: Add support for processors described as container packages") Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/acpi/acpi_processor.c | 22 ---------------------- 1 file changed, 22 deletions(-) diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 0ff69af46a50..d46e1fe25d58 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -698,31 +698,9 @@ static struct acpi_scan_handler processor_handler = { }, }; -static acpi_status acpi_processor_container_walk(acpi_handle handle, - u32 lvl, - void *context, - void **rv) -{ - struct acpi_device *adev; - acpi_status status; - - adev = acpi_get_acpi_dev(handle); - if (!adev) - return AE_ERROR; - - status = acpi_processor_add(adev, &processor_device_ids[0]); - acpi_put_acpi_dev(adev); - - return status; -} - static int acpi_processor_container_attach(struct acpi_device *dev, const struct acpi_device_id *id) { - acpi_walk_namespace(ACPI_TYPE_PROCESSOR, dev->handle, - ACPI_UINT32_MAX, acpi_processor_container_walk, - NULL, NULL, NULL); - return 1; } -- 2.25.1

2 1

[PATCH OLK-5.10 0/2] CVE-2024-39469
by Yu Liao 04 Jul '24

04 Jul '24

CVE-2024-39469 Matthew Wilcox (Oracle) (1): nilfs2: return the mapped address from nilfs_get_page() Ryusuke Konishi (1): nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors fs/nilfs2/dir.c | 59 +++++++++++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 31 deletions(-) -- 2.33.0

2 3

[PATCH openEuler-1.0-LTS 0/2] Fix CVE-2024-36949
by Zheng Zucheng 04 Jul '24

04 Jul '24

Mukul Joshi (1): drm/amdkfd: Rework kfd_locked handling Zhigang Luo (1): amd/amdkfd: sync all devices to wait all processes being evicted drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 3 --- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 27 +++++++++++++++--------- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 + drivers/gpu/drm/amd/amdkfd/kfd_process.c | 8 ++++++- 4 files changed, 25 insertions(+), 14 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS V1] USB: core: Fix hang in usb_kill_urb by adding memory barriers
by Cheng Yu 04 Jul '24

04 Jul '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v5.10.96 commit e3b131e30e612ff0e32de6c1cb4f69f89db29193 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72HV CVE: CVE-2022-48760 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 26fbe9772b8c459687930511444ce443011f86bf upstream. The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received. The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions: CPU 0 CPU 1 ---------------------------- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count; whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject. This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb(). The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb(). The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs. The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect. This patch adds the necessary memory barriers. CC: <stable(a)vger.kernel.org> Reported-and-tested-by: syzbot+76629376e06e2c2ad626(a)syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Link: https://lore.kernel.org/r/Ye8K0QYee0Q0Nna2@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/usb/core/hcd.c | 14 ++++++++++++++ drivers/usb/core/urb.c | 12 ++++++++++++ 2 files changed, 26 insertions(+) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 62e6c526e6ed..acff95a9f239 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1663,6 +1663,13 @@ int usb_hcd_submit_urb (struct urb *urb, gfp_t mem_flags) urb->hcpriv = NULL; INIT_LIST_HEAD(&urb->urb_list); atomic_dec(&urb->use_count); + /* + * Order the write of urb->use_count above before the read + * of urb->reject below. Pairs with the memory barriers in + * usb_kill_urb() and usb_poison_urb(). + */ + smp_mb__after_atomic(); + atomic_dec(&urb->dev->urbnum); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); @@ -1772,6 +1779,13 @@ static void __usb_hcd_giveback_urb(struct urb *urb) usb_anchor_resume_wakeups(anchor); atomic_dec(&urb->use_count); + /* + * Order the write of urb->use_count above before the read + * of urb->reject below. Pairs with the memory barriers in + * usb_kill_urb() and usb_poison_urb(). + */ + smp_mb__after_atomic(); + if (unlikely(atomic_read(&urb->reject))) wake_up(&usb_kill_urb_queue); usb_put_urb(urb); diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c index 5e844097a9e3..abf4681159df 100644 --- a/drivers/usb/core/urb.c +++ b/drivers/usb/core/urb.c @@ -692,6 +692,12 @@ void usb_kill_urb(struct urb *urb) if (!(urb && urb->dev && urb->ep)) return; atomic_inc(&urb->reject); + /* + * Order the write of urb->reject above before the read + * of urb->use_count below. Pairs with the barriers in + * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). + */ + smp_mb__after_atomic(); usb_hcd_unlink_urb(urb, -ENOENT); wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); @@ -733,6 +739,12 @@ void usb_poison_urb(struct urb *urb) if (!urb) return; atomic_inc(&urb->reject); + /* + * Order the write of urb->reject above before the read + * of urb->use_count below. Pairs with the barriers in + * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). + */ + smp_mb__after_atomic(); if (!urb->dev || !urb->ep) return; -- 2.25.1

2 1