- Linux-stable-mirror - lists.linaro.org

[PATCH] drm/i915/gem: NULL-initialize the eb->vma[].vma pointers in gem_do_execbuffer

by Krzysztof Niemiec

Initialize eb->vma[].vma pointers to NULL when the eb structure is first set up. During the execution of eb_lookup_vmas(), the eb->vma array is successively filled up with struct eb_vma objects. This process includes calling eb_add_vma(), which might fail; however, even in the event of failure, eb->vma[i].vma is set for the currently processed buffer. If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which prompts a call to eb_release_vmas() to clean up the mess. Since eb_lookup_vmas() might fail during processing any (possibly not first) buffer, eb_release_vmas() checks whether a buffer's vma is NULL to know at what point did the lookup function fail. In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helper function eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma is set to NULL in case i915_gem_object_userptr_submit_init() fails; the current one needs to be cleaned up by eb_release_vmas() at this point, so the next one is set. If eb_add_vma() fails, neither the current nor the next vma is nullified, which is a source of a NULL deref bug described in [1]. When entering eb_lookup_vmas(), the vma pointers are set to the slab poison value, instead of NULL. This doesn't matter for the actual lookup, since it gets overwritten anyway, however the eb_release_vmas() function only recognizes NULL as the stopping value, hence the pointers are being nullified as they go in case of intermediate failure. This patch changes the approach to filling them all with NULL at the start instead, rather than handling that manually during failure. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15062 Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf") Reported-by: Gangmin Kim <km.kim1503(a)gmail.com> Cc: <stable(a)vger.kernel.org> # 5.16.x Signed-off-by: Krzysztof Niemiec <krzysztof.niemiec(a)intel.com> --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 27 ++++++------------- 1 file changed, 8 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index b057c2fa03a4..02120203af55 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -951,13 +951,13 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) vma = eb_lookup_vma(eb, eb->exec[i].handle); if (IS_ERR(vma)) { err = PTR_ERR(vma); - goto err; + return err; } err = eb_validate_vma(eb, &eb->exec[i], vma); if (unlikely(err)) { i915_vma_put(vma); - goto err; + return err; } err = eb_add_vma(eb, &current_batch, i, vma); @@ -966,19 +966,8 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) if (i915_gem_object_is_userptr(vma->obj)) { err = i915_gem_object_userptr_submit_init(vma->obj); - if (err) { - if (i + 1 < eb->buffer_count) { - /* - * Execbuffer code expects last vma entry to be NULL, - * since we already initialized this entry, - * set the next value to NULL or we mess up - * cleanup handling. - */ - eb->vma[i + 1].vma = NULL; - } - + if (err) return err; - } eb->vma[i].flags |= __EXEC_OBJECT_USERPTR_INIT; eb->args->flags |= __EXEC_USERPTR_USED; @@ -986,10 +975,6 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb) } return 0; - -err: - eb->vma[i].vma = NULL; - return err; } static int eb_lock_vmas(struct i915_execbuffer *eb) @@ -3362,6 +3347,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, struct sync_file *out_fence = NULL; int out_fence_fd = -1; int err; + int i; BUILD_BUG_ON(__EXEC_INTERNAL_FLAGS & ~__I915_EXEC_ILLEGAL_FLAGS); BUILD_BUG_ON(__EXEC_OBJECT_INTERNAL_FLAGS & @@ -3375,7 +3361,10 @@ i915_gem_do_execbuffer(struct drm_device *dev, eb.exec = exec; eb.vma = (struct eb_vma *)(exec + args->buffer_count + 1); - eb.vma[0].vma = NULL; + + for (i = 0; i < args->buffer_count; i++) + eb.vma[i].vma = NULL; + eb.batch_pool = NULL; eb.invalid_flags = __EXEC_OBJECT_UNKNOWN_FLAGS; -- 2.45.2

19 hours, 43 minutes

4
8
0 0

[REGRESSION] stable-rc/linux-6.1.y: (build) variable 'clidr' is uninitialized when passed as a const pointer a...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.1.y: --- variable 'clidr' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] in arch/arm64/kvm/sys_regs.o (arch/arm64/kvm/sys_regs.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:20aa3d9f2fb39bcb7ec7ca6a54be07b6b2668acb - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 87757e18cdafe3f3dd4fc9b9e920e6416e6d00eb Please include the KernelCI tag when submitting a fix: Reported-by: kernelci.org bot <bot(a)kernelci.org> Log excerpt: ===================================================== arch/arm64/kvm/sys_regs.c:3002:23: error: variable 'clidr' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 3002 | get_clidr_el1(NULL, &clidr); /* Ugly... */ | ^~~~~ CC block/partitions/aix.o 1 error generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig on (arm64): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-arm64-allmodconfig-69286db7f5b87… - dashboard: https://d.kernelci.org/build/maestro:69286db7f5b8743b1f65f467 #kernelci issue maestro:20aa3d9f2fb39bcb7ec7ca6a54be07b6b2668acb -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

19 hours, 49 minutes

1
0
0 0

[PATCH v3] HID: memory leak in dualshock4_get_calibration_data

by Eslam Khafagy

Function dualshock4_get_calibration_data allocates memory to pointer buf .However, the function may exit prematurely due to transfer_failure in this case it does not handle freeing memory. This patch handles memory deallocation at exit. Reported-by: syzbot+4f5f81e1456a1f645bf8(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/691560c4.a70a0220.3124cb.0019.GAE@google.com/T/ Tested-by: syzbot+4f5f81e1456a1f645bf8(a)syzkaller.appspotmail.com Fixes: 947992c7fa9e0 ("HID: playstation: DS4: Fix calibration workaround for clone devices") Cc: stable(a)vger.kernel.org Signed-off-by: Eslam Khafagy <eslam.medhat1993(a)gmail.com> --- v3: * Address issues reported by checkpatch and re-format commit message for better readability * kfree() is safe so no need to check for NULL pointer v2: https://lore.kernel.org/all/20251116022723.29857-1-eslam.medhat1993@gmail.c… * Adding tag "Cc: stable(a)vger.kernel.org" v1: https://lore.kernel.org/all/20251115022323.1395726-1-eslam.medhat1993@gmail… drivers/hid/hid-playstation.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c index 128aa6abd10b..05a8522ace4f 100644 --- a/drivers/hid/hid-playstation.c +++ b/drivers/hid/hid-playstation.c @@ -1994,9 +1994,6 @@ static int dualshock4_get_calibration_data(struct dualshock4 *ds4) acc_z_plus = get_unaligned_le16(&buf[31]); acc_z_minus = get_unaligned_le16(&buf[33]); - /* Done parsing the buffer, so let's free it. */ - kfree(buf); - /* * Set gyroscope calibration and normalization parameters. * Data values will be normalized to 1/DS4_GYRO_RES_PER_DEG_S degree/s. @@ -2043,6 +2040,9 @@ static int dualshock4_get_calibration_data(struct dualshock4 *ds4) ds4->accel_calib_data[2].sens_denom = range_2g; transfer_failed: + /* First free buf if still allocated */ + kfree(buf); + /* * Sanity check gyro calibration data. This is needed to prevent crashes * during report handling of virtual, clone or broken devices not implementing -- 2.43.0

19 hours, 52 minutes

4
6
0 0

[PATCH v2 6.6] ksmbd: fix use-after-free in session logoff

by Nazar Kalashnikov

From: Sean Heelan <seanheelan(a)gmail.com> commit 2fc9feff45d92a92cd5f96487655d5be23fb7e2b upstream. The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user. Signed-off-by: Sean Heelan <seanheelan(a)gmail.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Nazar Kalashnikov <sivartiwe(a)gmail.com> --- v2: Fix duplicate From: header Backport fix for CVE-2025-37899 fs/smb/server/smb2pdu.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 9f64808c7917..a819f198c333 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2255,10 +2255,6 @@ int smb2_session_logoff(struct ksmbd_work *work) sess->state = SMB2_SESSION_EXPIRED; up_write(&conn->session_lock); - if (sess->user) { - ksmbd_free_user(sess->user); - sess->user = NULL; - } ksmbd_all_conn_set_status(sess_id, KSMBD_SESS_NEED_SETUP); rsp->StructureSize = cpu_to_le16(4); -- 2.43.0

20 hours, 24 minutes

1
0
0 0

[PATCH v2 6.1] ksmbd: fix use-after-free in session logoff

by Nazar Kalashnikov

From: Sean Heelan <seanheelan(a)gmail.com> commit 2fc9feff45d92a92cd5f96487655d5be23fb7e2b upstream. The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user. Signed-off-by: Sean Heelan <seanheelan(a)gmail.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Nazar Kalashnikov <sivartiwe(a)gmail.com> --- v2: Fix duplicate From: header Backport fix for CVE-2025-37899 fs/smb/server/smb2pdu.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index d2dca5d2f17c..f72ef3fe4968 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2252,10 +2252,6 @@ int smb2_session_logoff(struct ksmbd_work *work) sess->state = SMB2_SESSION_EXPIRED; up_write(&conn->session_lock); - if (sess->user) { - ksmbd_free_user(sess->user); - sess->user = NULL; - } ksmbd_all_conn_set_status(sess_id, KSMBD_SESS_NEED_NEGOTIATE); rsp->StructureSize = cpu_to_le16(4); -- 2.39.2

20 hours, 34 minutes

1
0
0 0

Re: [PATCH 6.1] ksmbd: fix use-after-free in session logoff

by SIVARTIWE PROST

Sorry about that! I will send the revised second version shortly

20 hours, 36 minutes

1
0
0 0

[PATCH] hwmon: (max6697) fix regmap leak on probe failure

by Johan Hovold

The i2c regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: 3a2a8cc3fe24 ("hwmon: (max6697) Convert to use regmap") Cc: stable(a)vger.kernel.org # 6.12 Cc: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/hwmon/max6697.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwmon/max6697.c b/drivers/hwmon/max6697.c index 0735a1d2c20f..6926d787b5ad 100644 --- a/drivers/hwmon/max6697.c +++ b/drivers/hwmon/max6697.c @@ -548,7 +548,7 @@ static int max6697_probe(struct i2c_client *client) struct regmap *regmap; int err; - regmap = regmap_init_i2c(client, &max6697_regmap_config); + regmap = devm_regmap_init_i2c(client, &max6697_regmap_config); if (IS_ERR(regmap)) return PTR_ERR(regmap); -- 2.51.2

20 hours, 39 minutes

2
1
0 0

[REGRESSION] stable-rc/linux-5.4.y: (build) GCC does not allow variable declarations in for loop initializers ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: --- GCC does not allow variable declarations in for loop initializers before C99 [-Wgcc-compat] in mm/mempool.o (mm/mempool.c) [logspec:kbuild,kbuild.compiler.warning] --- - dashboard: https://d.kernelci.org/i/maestro:d414057925e4dea9704ce677eef188319c8610a4 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: b11ac6e8f913ac67f9424a5cdd4158b283c0e3cb Please include the KernelCI tag when submitting a fix: Reported-by: kernelci.org bot <bot(a)kernelci.org> Log excerpt: ===================================================== mm/mempool.c:69:8: warning: GCC does not allow variable declarations in for loop initializers before C99 [-Wgcc-compat] 69 | for (int i = 0; i < (1 << order); i++) { | ^ CC arch/arm/mach-imx/mach-vpr200.o mm/mempool.c:71:17: error: implicit declaration of function 'kmap_local_page' [-Werror,-Wimplicit-function-declaration] 71 | void *addr = kmap_local_page(page + i); | ^ mm/mempool.c:71:17: note: did you mean 'kmap_to_page'? ./include/linux/highmem.h:67:14: note: 'kmap_to_page' declared here 67 | struct page *kmap_to_page(void *addr); | ^ mm/mempool.c:71:10: error: incompatible integer to pointer conversion initializing 'void *' with an expression of type 'int' [-Wint-conversion] 71 | void *addr = kmap_local_page(page + i); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~ mm/mempool.c:74:4: error: implicit declaration of function 'kunmap_local' [-Werror,-Wimplicit-function-declaration] 74 | kunmap_local(addr); | ^ mm/mempool.c:103:8: warning: GCC does not allow variable declarations in for loop initializers before C99 [-Wgcc-compat] 103 | for (int i = 0; i < (1 << order); i++) { | ^ mm/mempool.c:105:17: error: implicit declaration of function 'kmap_local_page' [-Werror,-Wimplicit-function-declaration] 105 | void *addr = kmap_local_page(page + i); | ^ mm/mempool.c:105:10: error: incompatible integer to pointer conversion initializing 'void *' with an expression of type 'int' [-Wint-conversion] 105 | void *addr = kmap_local_page(page + i); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~ mm/mempool.c:108:4: error: implicit declaration of function 'kunmap_local' [-Werror,-Wimplicit-function-declaration] 108 | kunmap_local(addr); | ^ 2 warnings and 6 errors generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-arm-allmodconfig-69286c4df5b8743… - dashboard: https://d.kernelci.org/build/maestro:69286c4df5b8743b1f65f308 #kernelci issue maestro:d414057925e4dea9704ce677eef188319c8610a4 -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

20 hours, 49 minutes

1
0
0 0

[REGRESSION] stable-rc/linux-5.10.y: (build) GCC does not allow variable declarations in for loop initializers ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: --- GCC does not allow variable declarations in for loop initializers before C99 [-Wgcc-compat] in mm/mempool.o (mm/mempool.c) [logspec:kbuild,kbuild.compiler.warning] --- - dashboard: https://d.kernelci.org/i/maestro:edfc0791be4ae7547a2a17054e9cd0317c106f20 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 92a27d160c829ca1d8dd3be92e8e8669620d66d5 Please include the KernelCI tag when submitting a fix: Reported-by: kernelci.org bot <bot(a)kernelci.org> Log excerpt: ===================================================== mm/mempool.c:68:8: warning: GCC does not allow variable declarations in for loop initializers before C99 [-Wgcc-compat] 68 | for (int i = 0; i < (1 << order); i++) { | ^ mm/mempool.c:70:17: error: implicit declaration of function 'kmap_local_page' [-Werror,-Wimplicit-function-declaration] 70 | void *addr = kmap_local_page(page + i); | ^ mm/mempool.c:70:17: note: did you mean 'kmap_to_page'? ./include/linux/highmem.h:124:14: note: 'kmap_to_page' declared here 124 | struct page *kmap_to_page(void *addr); | ^ mm/mempool.c:70:10: error: incompatible integer to pointer conversion initializing 'void *' with an expression of type 'int' [-Wint-conversion] 70 | void *addr = kmap_local_page(page + i); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~ mm/mempool.c:73:4: error: implicit declaration of function 'kunmap_local' [-Werror,-Wimplicit-function-declaration] 73 | kunmap_local(addr); | ^ mm/mempool.c:101:8: warning: GCC does not allow variable declarations in for loop initializers before C99 [-Wgcc-compat] 101 | for (int i = 0; i < (1 << order); i++) { | ^ mm/mempool.c:103:17: error: implicit declaration of function 'kmap_local_page' [-Werror,-Wimplicit-function-declaration] 103 | void *addr = kmap_local_page(page + i); | ^ mm/mempool.c:103:10: error: incompatible integer to pointer conversion initializing 'void *' with an expression of type 'int' [-Wint-conversion] 103 | void *addr = kmap_local_page(page + i); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~ mm/mempool.c:106:4: error: implicit declaration of function 'kunmap_local' [-Werror,-Wimplicit-function-declaration] 106 | kunmap_local(addr); | ^ CC fs/notify/fanotify/fanotify.o 2 warnings and 6 errors generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-arm-allmodconfig-69286cb5f5b8743… - dashboard: https://d.kernelci.org/build/maestro:69286cb5f5b8743b1f65f372 ## i386_defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (i386): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-i386-allmodconfig-69286ceff5b874… - dashboard: https://d.kernelci.org/build/maestro:69286ceff5b8743b1f65f3b6 #kernelci issue maestro:edfc0791be4ae7547a2a17054e9cd0317c106f20 -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

20 hours, 49 minutes

1
0
0 0

[REGRESSION] stable-rc/linux-5.15.y: (build) GCC does not allow variable declarations in for loop initializers ...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.15.y: --- GCC does not allow variable declarations in for loop initializers before C99 [-Werror,-Wgcc-compat] in mm/mempool.o (mm/mempool.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:5387ce1530c340d198d1f318d34f9904675295a1 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 0001989708674740432a288983eddc1fdad1073b Please include the KernelCI tag when submitting a fix: Reported-by: kernelci.org bot <bot(a)kernelci.org> Log excerpt: ===================================================== mm/mempool.c:68:8: error: GCC does not allow variable declarations in for loop initializers before C99 [-Werror,-Wgcc-compat] 68 | for (int i = 0; i < (1 << order); i++) { | ^ mm/mempool.c:101:8: error: GCC does not allow variable declarations in for loop initializers before C99 [-Werror,-Wgcc-compat] 101 | for (int i = 0; i < (1 << order); i++) { | ^ CC kernel/irq/spurious.o 2 errors generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-arm-allmodconfig-69286d2ef5b8743… - dashboard: https://d.kernelci.org/build/maestro:69286d2ef5b8743b1f65f3ee ## i386_defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (i386): - compiler: clang-21 - config: https://files.kernelci.org/kbuild-clang-21-i386-allmodconfig-69286d6ff5b874… - dashboard: https://d.kernelci.org/build/maestro:69286d6ff5b8743b1f65f41f #kernelci issue maestro:5387ce1530c340d198d1f318d34f9904675295a1 -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

20 hours, 49 minutes

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror