* CVE-2023-52823: kernel: kexec: copy user-array safely @ 2024-05-21 15:31 Greg Kroah-Hartman 2024-05-24 10:02 ` Jiri Bohac 0 siblings, 1 reply; 13+ messages in thread From: Greg Kroah-Hartman @ 2024-05-21 15:31 UTC (permalink / raw) To: linux-cve-announce; +Cc: Greg Kroah-Hartman Description =========== In the Linux kernel, the following vulnerability has been resolved: kernel: kexec: copy user-array safely Currently, there is no overflow-check with memdup_user(). Use the new function memdup_array_user() instead of memdup_user() for duplicating the user-space array safely. The Linux kernel CVE team has assigned CVE-2023-52823 to this issue. Affected and fixed versions =========================== Fixed in 5.15.140 with commit d4f2c09d4672 Fixed in 6.1.64 with commit 8332523b13db Fixed in 6.5.13 with commit b0ed017a2b97 Fixed in 6.6.3 with commit 4fc857cc5cb9 Fixed in 6.7 with commit 569c8d82f95e Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2023-52823 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: kernel/kexec.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/d4f2c09d4672f0e997ba4b1b589cc376be7ec938 https://git.kernel.org/stable/c/8332523b13dbfcce60f631dfb34ac90df021b4bd https://git.kernel.org/stable/c/b0ed017a2b9735753eb95798d9f60176480424ca https://git.kernel.org/stable/c/4fc857cc5cb9b7ce6940898857d773564973a584 https://git.kernel.org/stable/c/569c8d82f95eb5993c84fb61a649a9c4ddd208b3 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: CVE-2023-52823: kernel: kexec: copy user-array safely 2024-05-21 15:31 CVE-2023-52823: kernel: kexec: copy user-array safely Greg Kroah-Hartman @ 2024-05-24 10:02 ` Jiri Bohac 0 siblings, 0 replies; 13+ messages in thread From: Jiri Bohac @ 2024-05-24 10:02 UTC (permalink / raw) To: cve, linux-kernel Cc: linux-cve-announce, Greg Kroah-Hartman, Eric Biederman, kexec On Tue, May 21, 2024 at 05:31:59PM +0200, Greg Kroah-Hartman wrote: > kernel: kexec: copy user-array safely > > Currently, there is no overflow-check with memdup_user(). This is false. Therefore, I'd like to dispute this CVE. The overflow check is in the kexec_load_check() function called shortly before the memdup_user() call: SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments, struct kexec_segment __user *, segments, unsigned long, flags) { result = kexec_load_check(nr_segments, flags); if (result) return result; ... ksegments = memdup_user(segments, nr_segments * sizeof(ksegments[0])); ... } #define KEXEC_SEGMENT_MAX 16 static inline int kexec_load_check(unsigned long nr_segments, unsigned long flags) { ... if (nr_segments > KEXEC_SEGMENT_MAX) return -EINVAL; } Thanks, -- Jiri Bohac <jbohac@suse.cz> SUSE Labs, Prague, Czechia _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: CVE-2023-52823: kernel: kexec: copy user-array safely @ 2024-05-24 10:02 ` Jiri Bohac 0 siblings, 0 replies; 13+ messages in thread From: Jiri Bohac @ 2024-05-24 10:02 UTC (permalink / raw) To: cve, linux-kernel Cc: linux-cve-announce, Greg Kroah-Hartman, Eric Biederman, kexec On Tue, May 21, 2024 at 05:31:59PM +0200, Greg Kroah-Hartman wrote: > kernel: kexec: copy user-array safely > > Currently, there is no overflow-check with memdup_user(). This is false. Therefore, I'd like to dispute this CVE. The overflow check is in the kexec_load_check() function called shortly before the memdup_user() call: SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments, struct kexec_segment __user *, segments, unsigned long, flags) { result = kexec_load_check(nr_segments, flags); if (result) return result; ... ksegments = memdup_user(segments, nr_segments * sizeof(ksegments[0])); ... } #define KEXEC_SEGMENT_MAX 16 static inline int kexec_load_check(unsigned long nr_segments, unsigned long flags) { ... if (nr_segments > KEXEC_SEGMENT_MAX) return -EINVAL; } Thanks, -- Jiri Bohac <jbohac@suse.cz> SUSE Labs, Prague, Czechia ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: CVE-2023-52823: kernel: kexec: copy user-array safely 2024-05-24 10:02 ` Jiri Bohac @ 2024-05-24 10:15 ` Greg Kroah-Hartman -1 siblings, 0 replies; 13+ messages in thread From: Greg Kroah-Hartman @ 2024-05-24 10:15 UTC (permalink / raw) To: Jiri Bohac; +Cc: cve, linux-kernel, linux-cve-announce, Eric Biederman, kexec On Fri, May 24, 2024 at 12:02:10PM +0200, Jiri Bohac wrote: > On Tue, May 21, 2024 at 05:31:59PM +0200, Greg Kroah-Hartman wrote: > > kernel: kexec: copy user-array safely > > > > Currently, there is no overflow-check with memdup_user(). > > This is false. > Therefore, I'd like to dispute this CVE. > > The overflow check is in the kexec_load_check() > function called shortly before the memdup_user() call: > > > SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments, > struct kexec_segment __user *, segments, unsigned long, flags) > { > result = kexec_load_check(nr_segments, flags); > if (result) > return result; > ... > ksegments = memdup_user(segments, nr_segments * sizeof(ksegments[0])); > ... > } > > #define KEXEC_SEGMENT_MAX 16 > static inline int kexec_load_check(unsigned long nr_segments, > unsigned long flags) > { > ... > if (nr_segments > KEXEC_SEGMENT_MAX) > return -EINVAL; > } Nice, but then why was this commit worded this way? Now we check twice? Double safe? Should it be reverted? I'll go revoke this, thanks for the review! greg k-h _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: CVE-2023-52823: kernel: kexec: copy user-array safely @ 2024-05-24 10:15 ` Greg Kroah-Hartman 0 siblings, 0 replies; 13+ messages in thread From: Greg Kroah-Hartman @ 2024-05-24 10:15 UTC (permalink / raw) To: Jiri Bohac; +Cc: cve, linux-kernel, linux-cve-announce, Eric Biederman, kexec On Fri, May 24, 2024 at 12:02:10PM +0200, Jiri Bohac wrote: > On Tue, May 21, 2024 at 05:31:59PM +0200, Greg Kroah-Hartman wrote: > > kernel: kexec: copy user-array safely > > > > Currently, there is no overflow-check with memdup_user(). > > This is false. > Therefore, I'd like to dispute this CVE. > > The overflow check is in the kexec_load_check() > function called shortly before the memdup_user() call: > > > SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments, > struct kexec_segment __user *, segments, unsigned long, flags) > { > result = kexec_load_check(nr_segments, flags); > if (result) > return result; > ... > ksegments = memdup_user(segments, nr_segments * sizeof(ksegments[0])); > ... > } > > #define KEXEC_SEGMENT_MAX 16 > static inline int kexec_load_check(unsigned long nr_segments, > unsigned long flags) > { > ... > if (nr_segments > KEXEC_SEGMENT_MAX) > return -EINVAL; > } Nice, but then why was this commit worded this way? Now we check twice? Double safe? Should it be reverted? I'll go revoke this, thanks for the review! greg k-h ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: CVE-2023-52823: kernel: kexec: copy user-array safely 2024-05-24 10:15 ` Greg Kroah-Hartman @ 2024-05-24 12:38 ` Jiri Bohac -1 siblings, 0 replies; 13+ messages in thread From: Jiri Bohac @ 2024-05-24 12:38 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: cve, linux-kernel, linux-cve-announce, Eric Biederman, kexec On Fri, May 24, 2024 at 12:15:47PM +0200, Greg Kroah-Hartman wrote: > Nice, but then why was this commit worded this way? Now we check twice? > Double safe? Should it be reverted? double safe's good; turning it into a CVE not so much :( CVE-2023-52822, CVE-2023-52824 and CVE-2023-52820, originally from the same patch series, seem to be the exact same case. CVE-2023-52822: int vmw_surface_define_ioctl(struct drm_device *dev, void *data, struct drm_file *file_priv) { ... if (num_sizes > DRM_VMW_MAX_SURFACE_FACES * DRM_VMW_MAX_MIP_LEVELS || num_sizes == 0) return -EINVAL; ... metadata->num_sizes = num_sizes; metadata->sizes = memdup_user((struct drm_vmw_size __user *)(unsigned long) req->size_addr, sizeof(*metadata->sizes) * metadata->num_sizes); } CVE-2023-52824 (here the check is in the immediately preceeding statement, could it be any more obvious?): long watch_queue_set_filter(struct pipe_inode_info *pipe, struct watch_notification_filter __user *_filter) { if (filter.nr_filters == 0 || filter.nr_filters > 16 || filter.__reserved != 0) return -EINVAL; tf = memdup_user(_filter->filters, filter.nr_filters * sizeof(*tf)); } CVE-2023-52820 is a little less obvious to be safe, but I believe it is: int drm_mode_create_lease_ioctl(struct drm_device *dev, void *data, struct drm_file *lessor_priv) { ... object_ids = memdup_user(u64_to_user_ptr(cl->object_ids), array_size(object_count, sizeof(__u32))); array_size() will safely multiply object_count * 4 and return SIZE_MAX on overflow, making the kmalloc inside memdup_user cleanly fail with -ENOMEM. > I'll go revoke this, thanks for the review! could you check and revoke all the above as well? Thanks, -- Jiri Bohac <jbohac@suse.cz> SUSE Labs, Prague, Czechia _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: CVE-2023-52823: kernel: kexec: copy user-array safely @ 2024-05-24 12:38 ` Jiri Bohac 0 siblings, 0 replies; 13+ messages in thread From: Jiri Bohac @ 2024-05-24 12:38 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: cve, linux-kernel, linux-cve-announce, Eric Biederman, kexec On Fri, May 24, 2024 at 12:15:47PM +0200, Greg Kroah-Hartman wrote: > Nice, but then why was this commit worded this way? Now we check twice? > Double safe? Should it be reverted? double safe's good; turning it into a CVE not so much :( CVE-2023-52822, CVE-2023-52824 and CVE-2023-52820, originally from the same patch series, seem to be the exact same case. CVE-2023-52822: int vmw_surface_define_ioctl(struct drm_device *dev, void *data, struct drm_file *file_priv) { ... if (num_sizes > DRM_VMW_MAX_SURFACE_FACES * DRM_VMW_MAX_MIP_LEVELS || num_sizes == 0) return -EINVAL; ... metadata->num_sizes = num_sizes; metadata->sizes = memdup_user((struct drm_vmw_size __user *)(unsigned long) req->size_addr, sizeof(*metadata->sizes) * metadata->num_sizes); } CVE-2023-52824 (here the check is in the immediately preceeding statement, could it be any more obvious?): long watch_queue_set_filter(struct pipe_inode_info *pipe, struct watch_notification_filter __user *_filter) { if (filter.nr_filters == 0 || filter.nr_filters > 16 || filter.__reserved != 0) return -EINVAL; tf = memdup_user(_filter->filters, filter.nr_filters * sizeof(*tf)); } CVE-2023-52820 is a little less obvious to be safe, but I believe it is: int drm_mode_create_lease_ioctl(struct drm_device *dev, void *data, struct drm_file *lessor_priv) { ... object_ids = memdup_user(u64_to_user_ptr(cl->object_ids), array_size(object_count, sizeof(__u32))); array_size() will safely multiply object_count * 4 and return SIZE_MAX on overflow, making the kmalloc inside memdup_user cleanly fail with -ENOMEM. > I'll go revoke this, thanks for the review! could you check and revoke all the above as well? Thanks, -- Jiri Bohac <jbohac@suse.cz> SUSE Labs, Prague, Czechia ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: CVE-2023-52823: kernel: kexec: copy user-array safely 2024-05-24 12:38 ` Jiri Bohac @ 2024-05-24 14:13 ` Jiri Bohac -1 siblings, 0 replies; 13+ messages in thread From: Jiri Bohac @ 2024-05-24 14:13 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: cve, linux-kernel, linux-cve-announce, Eric Biederman, kexec On Fri, May 24, 2024 at 02:38:04PM +0200, Jiri Bohac wrote: > On Fri, May 24, 2024 at 12:15:47PM +0200, Greg Kroah-Hartman wrote: > > Nice, but then why was this commit worded this way? Now we check twice? > > Double safe? Should it be reverted? > > double safe's good; turning it into a CVE not so much :( > CVE-2023-52822, CVE-2023-52824 and CVE-2023-52820, originally from the same patch > series, seem to be the exact same case. Same thing: CVE-2023-52758 -- Jiri Bohac <jbohac@suse.cz> SUSE Labs, Prague, Czechia _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: CVE-2023-52823: kernel: kexec: copy user-array safely @ 2024-05-24 14:13 ` Jiri Bohac 0 siblings, 0 replies; 13+ messages in thread From: Jiri Bohac @ 2024-05-24 14:13 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: cve, linux-kernel, linux-cve-announce, Eric Biederman, kexec On Fri, May 24, 2024 at 02:38:04PM +0200, Jiri Bohac wrote: > On Fri, May 24, 2024 at 12:15:47PM +0200, Greg Kroah-Hartman wrote: > > Nice, but then why was this commit worded this way? Now we check twice? > > Double safe? Should it be reverted? > > double safe's good; turning it into a CVE not so much :( > CVE-2023-52822, CVE-2023-52824 and CVE-2023-52820, originally from the same patch > series, seem to be the exact same case. Same thing: CVE-2023-52758 -- Jiri Bohac <jbohac@suse.cz> SUSE Labs, Prague, Czechia ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: CVE-2023-52823: kernel: kexec: copy user-array safely 2024-05-24 14:13 ` Jiri Bohac @ 2024-05-24 15:27 ` Greg Kroah-Hartman -1 siblings, 0 replies; 13+ messages in thread From: Greg Kroah-Hartman @ 2024-05-24 15:27 UTC (permalink / raw) To: Jiri Bohac; +Cc: cve, linux-kernel, linux-cve-announce, Eric Biederman, kexec On Fri, May 24, 2024 at 04:13:53PM +0200, Jiri Bohac wrote: > On Fri, May 24, 2024 at 02:38:04PM +0200, Jiri Bohac wrote: > > On Fri, May 24, 2024 at 12:15:47PM +0200, Greg Kroah-Hartman wrote: > > > Nice, but then why was this commit worded this way? Now we check twice? > > > Double safe? Should it be reverted? > > > > double safe's good; turning it into a CVE not so much :( > > CVE-2023-52822, CVE-2023-52824 and CVE-2023-52820, originally from the same patch > > series, seem to be the exact same case. > > Same thing: CVE-2023-52758 Agreed, now rejected, thanks for the review! greg k-h _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: CVE-2023-52823: kernel: kexec: copy user-array safely @ 2024-05-24 15:27 ` Greg Kroah-Hartman 0 siblings, 0 replies; 13+ messages in thread From: Greg Kroah-Hartman @ 2024-05-24 15:27 UTC (permalink / raw) To: Jiri Bohac; +Cc: cve, linux-kernel, linux-cve-announce, Eric Biederman, kexec On Fri, May 24, 2024 at 04:13:53PM +0200, Jiri Bohac wrote: > On Fri, May 24, 2024 at 02:38:04PM +0200, Jiri Bohac wrote: > > On Fri, May 24, 2024 at 12:15:47PM +0200, Greg Kroah-Hartman wrote: > > > Nice, but then why was this commit worded this way? Now we check twice? > > > Double safe? Should it be reverted? > > > > double safe's good; turning it into a CVE not so much :( > > CVE-2023-52822, CVE-2023-52824 and CVE-2023-52820, originally from the same patch > > series, seem to be the exact same case. > > Same thing: CVE-2023-52758 Agreed, now rejected, thanks for the review! greg k-h ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: CVE-2023-52823: kernel: kexec: copy user-array safely 2024-05-24 12:38 ` Jiri Bohac @ 2024-05-24 15:26 ` Greg Kroah-Hartman -1 siblings, 0 replies; 13+ messages in thread From: Greg Kroah-Hartman @ 2024-05-24 15:26 UTC (permalink / raw) To: Jiri Bohac; +Cc: cve, linux-kernel, linux-cve-announce, Eric Biederman, kexec On Fri, May 24, 2024 at 02:38:04PM +0200, Jiri Bohac wrote: > On Fri, May 24, 2024 at 12:15:47PM +0200, Greg Kroah-Hartman wrote: > > Nice, but then why was this commit worded this way? Now we check twice? > > Double safe? Should it be reverted? > > double safe's good; turning it into a CVE not so much :( > CVE-2023-52822, CVE-2023-52824 and CVE-2023-52820, originally from the same patch > series, seem to be the exact same case. > > CVE-2023-52822: > > int vmw_surface_define_ioctl(struct drm_device *dev, void *data, > struct drm_file *file_priv) > { > ... > if (num_sizes > DRM_VMW_MAX_SURFACE_FACES * DRM_VMW_MAX_MIP_LEVELS || > num_sizes == 0) > return -EINVAL; > ... > metadata->num_sizes = num_sizes; > metadata->sizes = > memdup_user((struct drm_vmw_size __user *)(unsigned long) > req->size_addr, > sizeof(*metadata->sizes) * metadata->num_sizes); > } Agreed, now rejected. > CVE-2023-52824 (here the check is in the immediately preceeding statement, could it > be any more obvious?): > > long watch_queue_set_filter(struct pipe_inode_info *pipe, > struct watch_notification_filter __user *_filter) > { > if (filter.nr_filters == 0 || > filter.nr_filters > 16 || > filter.__reserved != 0) > return -EINVAL; > > tf = memdup_user(_filter->filters, filter.nr_filters * sizeof(*tf)); > } Yup, now rejected. > > > CVE-2023-52820 is a little less obvious to be safe, but I believe it is: > > int drm_mode_create_lease_ioctl(struct drm_device *dev, > void *data, struct drm_file *lessor_priv) > { > ... > object_ids = memdup_user(u64_to_user_ptr(cl->object_ids), > array_size(object_count, sizeof(__u32))); > > array_size() will safely multiply object_count * 4 and return SIZE_MAX on > overflow, making the kmalloc inside memdup_user cleanly fail with -ENOMEM. Also agreed, now rejected. thanks, greg k-h _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: CVE-2023-52823: kernel: kexec: copy user-array safely @ 2024-05-24 15:26 ` Greg Kroah-Hartman 0 siblings, 0 replies; 13+ messages in thread From: Greg Kroah-Hartman @ 2024-05-24 15:26 UTC (permalink / raw) To: Jiri Bohac; +Cc: cve, linux-kernel, linux-cve-announce, Eric Biederman, kexec On Fri, May 24, 2024 at 02:38:04PM +0200, Jiri Bohac wrote: > On Fri, May 24, 2024 at 12:15:47PM +0200, Greg Kroah-Hartman wrote: > > Nice, but then why was this commit worded this way? Now we check twice? > > Double safe? Should it be reverted? > > double safe's good; turning it into a CVE not so much :( > CVE-2023-52822, CVE-2023-52824 and CVE-2023-52820, originally from the same patch > series, seem to be the exact same case. > > CVE-2023-52822: > > int vmw_surface_define_ioctl(struct drm_device *dev, void *data, > struct drm_file *file_priv) > { > ... > if (num_sizes > DRM_VMW_MAX_SURFACE_FACES * DRM_VMW_MAX_MIP_LEVELS || > num_sizes == 0) > return -EINVAL; > ... > metadata->num_sizes = num_sizes; > metadata->sizes = > memdup_user((struct drm_vmw_size __user *)(unsigned long) > req->size_addr, > sizeof(*metadata->sizes) * metadata->num_sizes); > } Agreed, now rejected. > CVE-2023-52824 (here the check is in the immediately preceeding statement, could it > be any more obvious?): > > long watch_queue_set_filter(struct pipe_inode_info *pipe, > struct watch_notification_filter __user *_filter) > { > if (filter.nr_filters == 0 || > filter.nr_filters > 16 || > filter.__reserved != 0) > return -EINVAL; > > tf = memdup_user(_filter->filters, filter.nr_filters * sizeof(*tf)); > } Yup, now rejected. > > > CVE-2023-52820 is a little less obvious to be safe, but I believe it is: > > int drm_mode_create_lease_ioctl(struct drm_device *dev, > void *data, struct drm_file *lessor_priv) > { > ... > object_ids = memdup_user(u64_to_user_ptr(cl->object_ids), > array_size(object_count, sizeof(__u32))); > > array_size() will safely multiply object_count * 4 and return SIZE_MAX on > overflow, making the kmalloc inside memdup_user cleanly fail with -ENOMEM. Also agreed, now rejected. thanks, greg k-h ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2024-05-24 15:27 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-05-21 15:31 CVE-2023-52823: kernel: kexec: copy user-array safely Greg Kroah-Hartman 2024-05-24 10:02 ` Jiri Bohac 2024-05-24 10:02 ` Jiri Bohac 2024-05-24 10:15 ` Greg Kroah-Hartman 2024-05-24 10:15 ` Greg Kroah-Hartman 2024-05-24 12:38 ` Jiri Bohac 2024-05-24 12:38 ` Jiri Bohac 2024-05-24 14:13 ` Jiri Bohac 2024-05-24 14:13 ` Jiri Bohac 2024-05-24 15:27 ` Greg Kroah-Hartman 2024-05-24 15:27 ` Greg Kroah-Hartman 2024-05-24 15:26 ` Greg Kroah-Hartman 2024-05-24 15:26 ` Greg Kroah-Hartman
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.