Nixpkgs security tracker

Login with GitHub

Dismissed suggestions

These automatic suggestions were dismissed after initial triaging.

to select a suggestion for revision.

View:
Compact
Detailed
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ksmbd: validate NTLMv2 response before updating session key

In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate NTLMv2 response before updating session key ksmbd_auth_ntlmv2() derives the NTLMv2 session key into sess->sess_key before it verifies the NTLMv2 response. ksmbd_decode_ntlmssp_auth_blob() then continues into KEY_XCH even when ksmbd_auth_ntlmv2() failed. With SMB3 multichannel binding, the failed authentication operates on an existing session and the session setup error path does not expire binding sessions. A client can send a binding session setup with a bad NT proof and KEY_XCH and still modify sess->sess_key before STATUS_LOGON_FAILURE is returned. Relevant path: smb2_sess_setup() -> conn->binding = true -> ntlm_authenticate() -> session_user() -> ksmbd_decode_ntlmssp_auth_blob() -> ksmbd_auth_ntlmv2() -> calc_ntlmv2_hash() -> hmac_md5_usingrawkey(..., sess->sess_key) -> crypto_memneq() returns mismatch -> KEY_XCH arc4_crypt(..., sess->sess_key, ...) -> out_err without expiring the binding session Derive the base session key into a local buffer and copy it to sess->sess_key only after the proof matches. Return immediately on authentication failure so KEY_XCH is only processed after successful authentication.

Affected products

Linux
  • <954d196bebb2b50151cb96454c72dc113b2af1ac
  • =<6.18.*
  • <5.15
  • =<7.1.*
  • ==5.15
  • <89ca7756d5566ba636bb9092cdbe57dab095e136
  • =<*
  • <b56400364aed5c34d6e1a0b493081290a5328a9c
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete add_device_complete() runs from the hci_cmd_sync_work kworker, which holds only hci_req_sync_lock and *not* hci_dev_lock. It calls hci_conn_params_lookup() and then dereferences the returned object (params->flags) without taking hci_dev_lock: params = hci_conn_params_lookup(hdev, &cp->addr.bdaddr, le_addr_type(cp->addr.type)); ... device_flags_changed(NULL, hdev, &cp->addr.bdaddr, cp->addr.type, hdev->conn_flags, params ? params->flags : 0); hci_conn_params_lookup() walks hdev->le_conn_params and is documented to require hdev->lock. A concurrent MGMT_OP_REMOVE_DEVICE (remove_device()), which does run under hci_dev_lock, can call hci_conn_params_free() to list_del() and kfree() the very object the lookup returned, so the subsequent params->flags read touches freed memory [0]. Hold hci_dev_lock() across the hci_conn_params_lookup() and the read of params->flags (and the matching event emission) so the lookup result cannot be freed by a concurrent remove_device() before it is used, honouring the locking contract of hci_conn_params_lookup(). [0]: (trailing page/memory-state dump trimmed) BUG: KASAN: slab-use-after-free in add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c:7671 Read of size 1 at addr ffff000017ab26c1 by task kworker/u9:8/388 CPU: 1 UID: 0 PID: 388 Comm: kworker/u9:8 Not tainted 7.0.11 #20 PREEMPT Hardware name: linux,dummy-virt (DT) Workqueue: hci0 hci_cmd_sync_work Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:499 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xb4/0xd4 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x118/0x5d8 mm/kasan/report.c:482 kasan_report+0xb0/0xf4 mm/kasan/report.c:595 __asan_report_load1_noabort+0x20/0x2c mm/kasan/report_generic.c:378 add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c:7671 hci_cmd_sync_work+0x14c/0x240 net/bluetooth/hci_sync.c:334 process_one_work+0x628/0xd38 kernel/workqueue.c:3289 process_scheduled_works kernel/workqueue.c:3372 [inline] worker_thread+0x7a8/0xac0 kernel/workqueue.c:3453 kthread+0x39c/0x444 kernel/kthread.c:436 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 Allocated by task 3401: kasan_save_stack+0x3c/0x64 mm/kasan/common.c:57 kasan_save_track+0x20/0x3c mm/kasan/common.c:78 kasan_save_alloc_info+0x40/0x54 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xd4/0xd8 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __kmalloc_cache_noprof+0x1b0/0x458 mm/slub.c:5385 kmalloc_noprof include/linux/slab.h:950 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] hci_conn_params_add+0x10c/0x4b0 net/bluetooth/hci_core.c:2279 hci_conn_params_set net/bluetooth/mgmt.c:5162 [inline] add_device+0x5b4/0xa54 net/bluetooth/mgmt.c:7755 hci_mgmt_cmd net/bluetooth/hci_sock.c:1721 [inline] hci_sock_sendmsg+0x10b4/0x1dd0 net/bluetooth/hci_sock.c:1841 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe0/0x128 net/socket.c:742 sock_write_iter+0x250/0x390 net/socket.c:1195 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x66c/0xab0 fs/read_write.c:688 ksys_write+0x1fc/0x24c fs/read_write.c:740 __do_sys_write fs/read_write.c:751 [inline] __se_sys_write fs/read_write.c:748 [inline] __arm64_sys_write+0x70/0xa4 fs/read_write.c:748 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x84/0x2a8 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0xe4/0x294 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x44/0x5c arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0xac arch/arm64/kernel/entry-common.c:724 el0t_64_sync_handler+0xa0/0xe4 arch/arm64/kernel/entry-common.c:743 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596 Freed by task 3740: kasan_save_stack+0x3c/0x64 ---truncated---

Affected products

Linux
  • <6.15
  • <6.15
  • <caed4a96d55757c139a899744657c032b6186665
  • =<6.18.*
  • <6.12.96
  • =<6.12.*
  • <fa85d985f614bc3feb343000f14a1072e99b0df1
  • <e4369e4e970f3fa4676b76be14c1d315c87f22b6
  • <6.6.145
  • ==6.15
  • =<7.1.*
  • <b346efa825b5e4386f19bc63f81141652d496ec4
  • ==7e370545b8bdb54ed7f1ae485d6d24d3b62a0b53
  • =<6.6.*
  • =<*
  • <9531014c60c804e16099885d4a98aedcf31bce8d
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
cpufreq: pcc: fix use-after-free and double free in _OSC evaluation

In the Linux kernel, the following vulnerability has been resolved: cpufreq: pcc: fix use-after-free and double free in _OSC evaluation pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the two-phase _OSC negotiation. Between the two calls it freed output.pointer but left output.length unchanged. Since acpi_evaluate_object() treats a non-zero length with a non-NULL pointer as an existing buffer to write into, the second call wrote into freed memory (use-after-free). The subsequent kfree(output.pointer) at out_free then freed the same pointer a second time (double free). Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER after freeing the first result, so ACPICA allocates a fresh buffer for each phase independently.

Affected products

Linux
  • <982c9f92d57bda2b769851ff6d90d43dcf5f3734
  • <8e454e9d0bc03446d610ee49abec9dfd424f6541
  • <632666a63116d8061c62a988d1ca39dcd6d27c9b
  • =<6.18.*
  • <0e3c739a2f6fc1de5b19a8839ab80696b9cb2a29
  • <a36ca93a8ba57464e521d70a337d37f069064111
  • <6ba6f6783be2ffeb2cbcdc9321c4b9f708f796f7
  • =<6.12.*
  • <5cdb25f144b101083d8bf3fd023ad87fbe6850d7
  • =<7.1.*
  • ==2.6.34
  • =<6.1.*
  • =<*
  • =<6.6.*
  • <266d3dd8b757b48a576e90f018b51f7b7563cc32
  • <2.6.34
  • =<5.15.*
  • =<5.10.*
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
binder: fix UAF in binder_free_transaction()

In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_free_transaction() In binder_free_transaction(), the t->to_proc is read under the t->lock. However, once the t->lock is dropped, the to_proc can die in parallel. This leads to a use-after-free error when we attempt to acquire its inner lock right afterwards: ================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x1a0 Write of size 4 at addr ffff00001125da70 by task B/672 CPU: 20 UID: 0 PID: 672 Comm: B Not tainted 7.1.0-rc6-00284-g8e65320d91cd #4 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x1a0 binder_free_transaction+0x8c/0x320 binder_send_failed_reply+0x21c/0x2f8 binder_thread_release+0x488/0x7e0 binder_ioctl+0x12c0/0x29a0 [...] Allocated by task 675: __kmalloc_cache_noprof+0x174/0x444 binder_open+0x118/0xb70 do_dentry_open+0x374/0x1040 vfs_open+0x58/0x3bc [...] Freed by task 212: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_proc_dec_tmpref+0x32c/0x5e0 binder_deferred_func+0xc48/0x104c process_one_work+0x53c/0xbc0 [...] ================================================================== To prevent this, pin the target thread (t->to_thread) to guarantee the target process remains alive. Undelivered transactions without a target thread are already safe, as the target process can only be the current context in those paths.

Affected products

Linux
  • <0be901ab1dcc4af59b88f2e324493bb283850167
  • ==a4a3c070b8760f71c8311399fa9bfe67c8629bca
  • <45df558c543bb5543bacc8065fd7c567740781e5
  • <5.2
  • =<7.1.*
  • =<6.1.*
  • =<5.15.*
  • ==5.2
  • =<5.10.*
  • <5.2
  • <4.20
  • <48aeda9f8039e4a6971d1804578efde7f2c01eda
  • <4.15
  • ==22068d49d09d2b3890e19d7b2048a33340f992da
  • =<6.6.*
  • <f223d27a546c1e1f48d38fd67760e78f068fe8c4
  • <d45ef513eed1abebfec90c3cfb6ae50c2a4182db
  • =<6.18.*
  • <0f15f0f6ca5df566275ce517f257af2559528b41
  • =<6.12.*
  • =<*
  • ==0e3b977a8f1be01dcfa0baae68851b1f55f2a0a9
  • <5602a43f251c3d75312df91a422675fc00ca3dce
  • <328ccf32acb87e8bbb1fe2b065068c574e4db2bf
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: hda/cs35l41: Fix firmware load work teardown

In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs35l41: Fix firmware load work teardown cs35l41_hda creates ALSA controls whose private data points at the cs35l41_hda object. The firmware load control can also queue fw_load_work. Those controls are not removed on component unbind, and device remove only cancels fw_load_work through cs35l41_remove_dsp(). That helper is skipped when halo_initialized is false. With firmware_autostart disabled, a firmware load can be requested before the DSP has been initialized. If the component or device is removed before the queued work runs, the worker can run after teardown and dereference driver state that is no longer valid. Track the created controls and remove them on unbind so no new control callback can reach the driver data or queue more work. Then cancel fw_load_work to drain any request that was already queued. Also cancel the work unconditionally during device remove before runtime PM teardown.

Affected products

Linux
  • <6.0
  • =<6.18.*
  • <ce0a903d0591e3e2c790c5b628802b08d1b287cc
  • =<6.12.*
  • <b65020d5398f499c09498c9786dba6d67ae57664
  • =<7.1.*
  • <d6a40a4d083ef74d00c8f9516cb5ff07ac70720b
  • ==6.0
  • =<*
  • <8947215c0136c9d905e4a46d824824f8b48a2e5b
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn() hci_abort_conn() read hci_skb_event(hdev->sent_cmd) when a connection was pending, but hdev->sent_cmd can be NULL while req_status is still HCI_REQ_PEND, leading to a NULL pointer dereference and a general protection fault from the hci_rx_work() receive path. Instead of inspecting hdev->sent_cmd, track the in-flight create connection command with a new per-connection HCI_CONN_CREATE flag and route all cancellation through hci_cancel_connect_sync(), which dispatches to a dedicated per-type cancel function. The create command is in exactly one of two states: still queued, or in flight. The cancel function holds cmd_sync_work_lock across the whole decision: the worker takes this lock to dequeue every entry, so while it is held a queued command cannot start running and an in-flight command cannot complete and let the next command become pending. This keeps the flag test and hci_cmd_sync_cancel() atomic with respect to the worker, so a queued command is simply dequeued, and an in-flight command owned by this connection is cancelled without the risk of cancelling an unrelated command that became pending in the meantime. CIS uses the same flag mechanism via HCI_CONN_CREATE_CIS but cannot be dequeued per-connection. hci_acl_create_conn_sync() and hci_le_create_conn_sync() clear HCI_CONN_CREATE after the create command completes, but the command status handler can free conn via hci_conn_del() (for example when the controller rejects the connection) while the worker is still blocked on the connection complete event. Hold a reference on conn across the create command so the flag can be cleared without a use-after-free.

Affected products

Linux
  • <61701912c58a05f6a043f097cc177a964abef348
  • <83b22d7f7c384564fa42c3cf19bec715c693d7a2
  • =<7.1.*
  • ==e4511a67fcdba9729d1c7cfc6d2e645c765ce801
  • =<6.1.*
  • ==4ab81f16c68a602b2b69e333ae08d8748a9398de
  • <b42cb640a0493d16b61ddd267420274be15efdc1
  • <6.6
  • ==6.6
  • <6.6
  • <903227b6168bb99fd57d4e3c9c1b5014986198e0
  • <12917f591cea1af36087dba5b9ec888652f0b42a
  • <6.5
  • =<6.6.*
  • =<6.18.*
  • =<6.12.*
  • <70c397b62ee015e19b3924d9da741c8dda017819
  • <6.1.118
  • =<*
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
isofs: bound Rock Ridge symlink components to the SL record

In the Linux kernel, the following vulnerability has been resolved: isofs: bound Rock Ridge symlink components to the SL record get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it. A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; get_symlink_chunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory. ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAP_SYS_ADMIN - so the record contents are attacker-controlled. Reject any component that does not fit in the remaining record bytes before using it. In get_symlink_chunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parse_rock_ridge_inode_internal() stop the inode-size walk.

Affected products

Linux
  • <5fa1d6a5ec2356d2107dead614437c66fa7138b1
  • <9830725078c8483c6831ec10222ae724806ea36b
  • =<6.18.*
  • <36fe7d25dbc40da0c6b1dd4513a4f69ac6164eee
  • <1015e1c4b2fadd9c09704e24738e46598778c869
  • =<6.12.*
  • <b5699642640d6cff357638738c5293985cd5a53d
  • =<7.1.*
  • <a22cb6bb54dc167047ea9e70d97dfbc2c15649e3
  • <2.6.12
  • =<*
  • =<6.6.*
  • ==2.6.12
  • <b736b12108fd116c41777628f5a333791604df26
  • =<5.15.*
  • =<6.1.*
  • =<5.10.*
  • <6bf41db09ef935d76fcc84ccf213b42c18de95ee
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup

In the Linux kernel, the following vulnerability has been resolved: ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup If acpi_nfit_init() fails after adding the acpi_desc object to the acpi_descs list, that object is never removed from that list because the acpi_nfit_shutdown() devm action is not added for the NFIT device in that case. Next, the acpi_nfit_init() failure causes acpi_nfit_probe() to fail, the acpi_desc object is freed, and a dangling pointer is left behind in the acpi_descs. Any subsequent ACPI Machine Check Exception will trigger nfit_handle_mce() which iterates over acpi_descs and so a use-after-free will occur. Moreover, if acpi_nfit_probe() returns 0 after installing a notify handler for the NFIT device and without allocating the acpi_desc object and setting the NFIT device's driver data pointer, the acpi_desc object will be allocated by acpi_nfit_update_notify() and acpi_nfit_init() will be called to initialize it. Regardless of whether or not acpi_nfit_init() fails in that case, the acpi_nfit_shutdown() devm action is not added for the NFIT device and acpi_desc is never removed from the acpi_descs list. If the acpi_desc object is freed subsequently on driver removal, any subsequent ACPI MCE will lead to a use-after-free like in the previous case. To address the first issue mentioned above, make acpi_nfit_probe() call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and to address the other one, add a remove callback to the driver and make it call acpi_nfit_shutdown(). Also, since it is now possible to pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it may not have been initialized, add checks against NULL for acpi_desc and its nvdimm_bus field to that function and make acpi_nfit_unregister() clear the latter after unregistering the NVDIMM bus.

Affected products

Linux
  • ==4.6
  • <b07d22a2d17ad6465c87bd5752bc70e4c16e0ee4
  • <6ff054cc02a763914773b026cacb429e5fbf64fa
  • <4.6
  • =<5.10.*
  • =<6.18.*
  • <ee82078e776ae31266cc70fdf62ac17c3c6f100a
  • =<6.12.*
  • <7d69235bdc581a4346e9bcd6a8bea37d3e1abd25
  • =<7.1.*
  • <df7c92216a1583a76cb0cbf2f21cd68870609b05
  • =<6.1.*
  • =<*
  • =<6.6.*
  • <38bf27511ef41bffebd157ec3eba41fc89ba59cd
  • =<5.15.*
  • <c127dbd832bd4b9aef8a749d9f491b74042f9b47
  • <3b2628f7682aea8d9ce09ad4b9a3bd144b451eaa
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: firewire: isight: bound the sample count to the packet payload

In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire: isight: bound the sample count to the packet payload isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length. count = be32_to_cpu(payload->sample_count); if (likely(count <= (length - 16) / 4)) isight_samples(isight, payload->samples, count); length is the iso header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples() then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area. The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate.

Affected products

Linux
  • <8e48a29813df8dd71503800b7acf69c12c035045
  • <3.0
  • <29b9667982e4df2ed7744f86b1144f8bb58eb698
  • =<6.18.*
  • <31a01b70bb90e3ef3147f308e2ea899e1d2485ca
  • <ebbffacda6733dcbcef601b5b523460f8d8b671e
  • <31da82b9676c6b112e7c72c7529e6812b919742a
  • =<5.15.*
  • =<6.12.*
  • ==3.0
  • =<7.1.*
  • <57e4d9043afc1eaddee8f50d11def6e65415d273
  • =<*
  • <3ed2fa1ed8cc65f910b8bbc0be3cc366b30f8478
  • =<6.1.*
  • =<6.6.*
  • <24423e0a9251d348c3f1fb0bb0e61b879e1e976c
  • =<5.10.*
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
staging: media: ipu7: fix double-free and use-after-free in error paths

In the Linux kernel, the following vulnerability has been resolved: staging: media: ipu7: fix double-free and use-after-free in error paths In both ipu7_isys_init() and ipu7_psys_init(), pdata is allocated and then passed to ipu7_bus_initialize_device(), which stores it in adev->pdata. The ipu7_bus_release() function frees adev->pdata when the device's reference count drops to zero. Two error paths incorrectly call kfree(pdata) after the device teardown has already freed it: 1. When ipu7_mmu_init() fails: put_device() is called, which drops the reference count to zero and triggers ipu7_bus_release() -> kfree(pdata). The subsequent kfree(pdata) is a double-free. 2. When ipu7_bus_add_device() fails: it calls auxiliary_device_uninit() internally, which calls put_device() -> ipu7_bus_release() -> kfree(pdata). The subsequent kfree(pdata) is again a double-free. Note that the kfree(pdata) when ipu7_bus_initialize_device() itself fails is correct, because in that case auxiliary_device_init() failed and the release function was never set up, so pdata must be freed manually. Additionally, the error code was not saved before calling put_device(), causing ERR_CAST() to dereference the already-freed adev pointer when constructing the return value. Fix this by saving the error from dev_err_probe() before put_device() and returning ERR_PTR() instead. Remove the redundant kfree(pdata) calls and fix the use-after-free in the return values of the two affected error paths.

Affected products

Linux
  • ==6.17
  • =<6.18.*
  • <6.17
  • <b5ddc7257bee71f5b8cf9083e2b0ac0427e9fbb3
  • =<7.1.*
  • =<*
  • <837c1f9655421055f751ed34745e820a54a27642
  • <d3a9a8cf2d7fd61a2f63df61f6cbc0a9bb007cc0