search for: check_add_overflow

...ze); gcc assumes that 'sizeof(*args) + size' can overflow, which would result in the problem. The problem is not new, only it is now no longer a warning but an error since W=1 has been enabled for the drm subsystem and since Werror is enabled for test builds. Rearrange arithmetic and use check_add_overflow() for validating the allocation size to avoid the overflow. Fixes: a61ddb4393ad ("drm: enable (most) W=1 warnings by default across the subsystem") Cc: Javier Martinez Canillas <javierm at redhat.com> Cc: Jani Nikula <jani.nikula at intel.com> Cc: Thomas Zimmermann <tzimme...

...ze); gcc assumes that 'sizeof(*args) + size' can overflow, which would result in the problem. The problem is not new, only it is now no longer a warning but an error since W=1 has been enabled for the drm subsystem and since Werror is enabled for test builds. Rearrange arithmetic and use check_add_overflow() for validating the allocation size to avoid the overflow. While at it, split assignments out of if conditions. Fixes: a61ddb4393ad ("drm: enable (most) W=1 warnings by default across the subsystem") Cc: Javier Martinez Canillas <javierm at redhat.com> Cc: Jani Nikula <jani.nik...

...gpuva_mgr.c b/drivers/gpu/drm/drm_gpuva_mgr.c > new file mode 100644 > index 000000000000..dee2235530d6 > --- /dev/null > +++ b/drivers/gpu/drm/drm_gpuva_mgr.c [...] > +static bool > +drm_gpuva_check_overflow(u64 addr, u64 range) > +{ > + u64 end; > + > + return WARN(check_add_overflow(addr, range, &end), > + "GPUVA address limited to %lu bytes.\n", sizeof(end)); > +} This produces a warning on 32 bit systems as sizeof() isn't necessarily an unsigned long. The fix below silences the warning. Thanks, Steve ---8<----- >From 9c7356580362b6ac46...

...> > > > So that could wrap around, even though the allocation may not. > > > > Better yet, since "sizeof(*args) + size" is repeated 3 times in the > > function, I'd recommend: > > > > ... > > u32 args_size; > > > > if (check_add_overflow(sizeof(*args), size, &args_size)) > > return -ENOMEM; > > if (args_size > sizeof(stack)) { > > if (!(args = kmalloc(args_size, GFP_KERNEL))) trivia: More typical kernel style would use separate alloc and test args = kmalloc(args_size, GFP_KERNEL); if (!args) &g...

...we want to get the kernel source to the position where we can meaningfully instrument arithmetic wrap-around conditions and catch them when they are unexpected, regardless of whether they are signed[2], unsigned[3], or pointer[4] types. Refactor open-coded unsigned wrap-around addition test to use check_add_overflow(), retaining the result for later usage (which removes the redundant open-coded addition). This paves the way to enabling the wrap-around sanitizers in the future. Link: https://git.kernel.org/linus/68df3755e383e6fecf2354a67b08f92f18536594 [1] Link: https://github.com/KSPP/linux/issues/26 [2] Link...

...^^^^^^^^^^^^^^^^^^^^ > > So that could wrap around, even though the allocation may not. > > Better yet, since "sizeof(*args) + size" is repeated 3 times in the > function, I'd recommend: > > ... > u32 args_size; > > if (check_add_overflow(sizeof(*args), size, &args_size)) > return -ENOMEM; > if (args_size > sizeof(stack)) { > if (!(args = kmalloc(args_size, GFP_KERNEL))) > return -ENOMEM; > } else { > args = (void *)stack; > } > ... > ret = nvif_o...

...ject, args, sizeof(*args) + size, NULL); ^^^^^^^^^^^^^^^^^^^^ So that could wrap around, even though the allocation may not. Better yet, since "sizeof(*args) + size" is repeated 3 times in the function, I'd recommend: ... u32 args_size; if (check_add_overflow(sizeof(*args), size, &args_size)) return -ENOMEM; if (args_size > sizeof(stack)) { if (!(args = kmalloc(args_size, GFP_KERNEL))) return -ENOMEM; } else { args = (void *)stack; } ... ret = nvif_object_ioctl(object, args, args_size, NULL); This...

...00644 --- a/arch/x86/kvm/kvmi.c +++ b/arch/x86/kvm/kvmi.c @@ -98,3 +98,96 @@ int kvmi_arch_cmd_vcpu_get_info(struct kvm_vcpu *vcpu, return 0; } + +int kvmi_arch_check_get_registers_req(const struct kvmi_msg_hdr *msg, + const struct kvmi_vcpu_get_registers *req) +{ + size_t req_size; + + if (check_add_overflow(sizeof(struct kvmi_vcpu_hdr), + struct_size(req, msrs_idx, req->nmsrs), + &req_size)) + return -1; + + if (msg->size < req_size) + return -1; + + return 0; +} + +static int kvmi_get_registers(struct kvm_vcpu *vcpu, u32 *mode, + struct kvm_regs *regs, + struct kv...

(adding linux-hardening at vger.kernel.org) Le 18/05/2024 ? 16:37, Guenter Roeck a ?crit?: > Trying to build parisc:allmodconfig with gcc 12.x or later results > in the following build error. > > drivers/gpu/drm/nouveau/nvif/object.c: In function 'nvif_object_mthd': > drivers/gpu/drm/nouveau/nvif/object.c:161:9: error: > 'memcpy' accessing 4294967264 or more

...PUVA_LAST, static __maybe_unused, + drm_gpuva_it) + +static int __drm_gpuva_insert(struct drm_gpuva_manager *mgr, + struct drm_gpuva *va); +static void __drm_gpuva_remove(struct drm_gpuva *va); + +static bool +drm_gpuva_check_overflow(u64 addr, u64 range) +{ + u64 end; + + return WARN(check_add_overflow(addr, range, &end), + "GPUVA address limited to %lu bytes.\n", sizeof(end)); +} + +static bool +drm_gpuva_in_mm_range(struct drm_gpuva_manager *mgr, u64 addr, u64 range) +{ + u64 end = addr + range; + u64 mm_start = mgr->mm_start; + u64 mm_end = mm_start + mgr->mm_range; +...

...uct mm_struct *mm) +{ + mrn->mm = mm; + RB_CLEAR_NODE(&mrn->interval_tree.rb); + mrn->interval_tree.start = start; + /* + * Note that the representation of the intervals in the interval tree + * considers the ending point as contained in the interval. + */ + if (length == 0 || + check_add_overflow(start, length - 1, &mrn->interval_tree.last)) + return -EOVERFLOW; + + /* pairs with mmdrop in mmu_range_notifier_remove() */ + mmgrab(mm); + + /* + * If some invalidate_range_start/end region is going on in parallel + * we don't know what VA ranges are affected, so we must assume thi...

...+ mni->mm = mm; + mni->ops = ops; + RB_CLEAR_NODE(&mni->interval_tree.rb); + mni->interval_tree.start = start; + /* + * Note that the representation of the intervals in the interval tree + * considers the ending point as contained in the interval. + */ + if (length == 0 || + check_add_overflow(start, length - 1, &mni->interval_tree.last)) + return -EOVERFLOW; + + /* Must call with a mmget() held */ + if (WARN_ON(atomic_read(&mm->mm_count) <= 0)) + return -EINVAL; + + /* pairs with mmdrop in mmu_interval_notifier_remove() */ + mmgrab(mm); + + /* + * If some invalidate_...

...mrn->interval_tree.rb); > + mrn->interval_tree.start = start; > + /* > + * Note that the representation of the intervals in the interval tree > + * considers the ending point as contained in the interval. Thanks for that comment! > + */ > + if (length == 0 || > + check_add_overflow(start, length - 1, &mrn->interval_tree.last)) > + return -EOVERFLOW; > + > + /* pairs with mmdrop in mmu_range_notifier_remove() */ > + mmgrab(mm); > + > + /* > + * If some invalidate_range_start/end region is going on in parallel > + * we don't know what VA ra...

...c __attribute__((unused)), + drm_gpuva_it) + +static int __drm_gpuva_insert(struct drm_gpuva_manager *mgr, + struct drm_gpuva *va); +static void __drm_gpuva_remove(struct drm_gpuva *va); + +static inline bool +drm_gpuva_check_overflow(u64 addr, u64 range) +{ + u64 end; + + return WARN(check_add_overflow(addr, range, &end), + "GPUVA address limited to %lu bytes.\n", sizeof(end)); +} + +static inline bool +drm_gpuva_in_mm_range(struct drm_gpuva_manager *mgr, u64 addr, u64 range) +{ + u64 end = addr + range; + u64 mm_start = mgr->mm_start; + u64 mm_end = mm_start + mgr->mm_ra...

...PUVA_LAST, static __maybe_unused, + drm_gpuva_it) + +static int __drm_gpuva_insert(struct drm_gpuva_manager *mgr, + struct drm_gpuva *va); +static void __drm_gpuva_remove(struct drm_gpuva *va); + +static bool +drm_gpuva_check_overflow(u64 addr, u64 range) +{ + u64 end; + + return WARN(check_add_overflow(addr, range, &end), + "GPUVA address limited to %lu bytes.\n", sizeof(end)); +} + +static bool +drm_gpuva_in_mm_range(struct drm_gpuva_manager *mgr, u64 addr, u64 range) +{ + u64 end = addr + range; + u64 mm_start = mgr->mm_start; + u64 mm_end = mm_start + mgr->mm_range; +...

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others

From: Jason Gunthorpe <jgg at mellanox.com> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell if the driver is interested. Half of them use an interval_tree, the others

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VMs (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place