rainbutterfly/cve_corpus huggingface dataset:
CVE-2024-56576 media: i2c: tc358743: Fix crash in the probe error path when using polling
In the Linux kernel, the following vulnerability has been resolved:

media: i2c: tc358743: Fix crash in the probe error path when using polling

If an error occurs in the probe() function, we should remove the polling
timer that was alarmed earlier, otherwise the timer is called with
arguments that are already freed, which results in a crash.

------------[ cut here ]------------
WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268
Modules linked in:
CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226
Hardware name: Diasom DS-RK3568-SOM-EVB (DT)
pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __run_timers+0x244/0x268
lr : __run_timers+0x1d4/0x268
sp : ffffff80eff2baf0
x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00
x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00
x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000
x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff
x17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e
x14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000
x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009
x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480
x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240
x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0
Call trace:
 __run_timers+0x244/0x268
 timer_expire_remote+0x50/0x68
 tmigr_handle_remote+0x388/0x39c
 run_timer_softirq+0x38/0x44
 handle_softirqs+0x138/0x298
 __do_softirq+0x14/0x20
 ____do_softirq+0x10/0x1c
 call_on_irq_stack+0x24/0x4c
 do_softirq_own_stack+0x1c/0x2c
 irq_exit_rcu+0x9c/0xcc
 el1_interrupt+0x48/0xc0
 el1h_64_irq_handler+0x18/0x24
 el1h_64_irq+0x7c/0x80
 default_idle_call+0x34/0x68
 do_idle+0x23c/0x294
 cpu_startup_entry+0x38/0x3c
 secondary_start_kernel+0x128/0x160
 __secondary_switched+0xb8/0xbc
---[ end trace 0000000000000000 ]---
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:23:18.792Z
CVE-2024-56577 media: mtk-jpeg: Fix null-ptr-deref during unload module
In the Linux kernel, the following vulnerability has been resolved:

media: mtk-jpeg: Fix null-ptr-deref during unload module

The workqueue should be destroyed in mtk_jpeg_core.c since commit
09aea13ecf6f ("media: mtk-jpeg: refactor some variables"), otherwise
the below calltrace can be easily triggered.

[  677.862514] Unable to handle kernel paging request at virtual address dfff800000000023
[  677.863633] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
...
[  677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: G           O       6.8.12-mtk+gfa1a78e5d24b+ #17
...
[  677.882838] pc : destroy_workqueue+0x3c/0x770
[  677.883413] lr : mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]
[  677.884314] sp : ffff80008ad974f0
[  677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070
[  677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690
[  677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000
[  677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0
[  677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10
[  677.889361] x14: 00000000f1f1f1f1 x13: 0000000000000000 x12: ffff7000115b2e4d
[  677.890285] x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9 : ffff80000aa43e90
[  677.891208] x8 : 00008fffeea4d1b4 x7 : ffff80008ad97267 x6 : 0000000000000001
[  677.892131] x5 : ffff80008ad97260 x4 : ffff7000115b2e4d x3 : 0000000000000000
[  677.893054] x2 : 0000000000000023 x1 : dfff800000000000 x0 : 0000000000000118
[  677.893977] Call trace:
[  677.894297]  destroy_workqueue+0x3c/0x770
[  677.894826]  mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]
[  677.895677]  devm_action_release+0x50/0x90
[  677.896211]  release_nodes+0xe8/0x170
[  677.896688]  devres_release_all+0xf8/0x178
[  677.897219]  device_unbind_cleanup+0x24/0x170
[  677.897785]  device_release_driver_internal+0x35c/0x480
[  677.898461]  device_release_driver+0x20/0x38
...
[  677.912665] ---[ end trace 0000000000000000 ]---
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:23:19.725Z
CVE-2024-56578 media: imx-jpeg: Set video drvdata before register video device
In the Linux kernel, the following vulnerability has been resolved:

media: imx-jpeg: Set video drvdata before register video device

The video drvdata should be set before the video device is registered,
otherwise video_drvdata() may return NULL in the open() file ops, and led
to oops.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:23:20.659Z
CVE-2024-56579 media: amphion: Set video drvdata before register video device
In the Linux kernel, the following vulnerability has been resolved:

media: amphion: Set video drvdata before register video device

The video drvdata should be set before the video device is registered,
otherwise video_drvdata() may return NULL in the open() file ops, and led
to oops.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:23:21.438Z
CVE-2024-56580 media: qcom: camss: fix error path on configuration of power domains
In the Linux kernel, the following vulnerability has been resolved:

media: qcom: camss: fix error path on configuration of power domains

There is a chance to meet runtime issues during configuration of CAMSS
power domains, because on the error path dev_pm_domain_detach() is
unexpectedly called with NULL or error pointer.

One of the simplest ways to reproduce the problem is to probe CAMSS
driver before registration of CAMSS power domains, for instance if
a platform CAMCC driver is simply not built.

Warning backtrace example:

    Unable to handle kernel NULL pointer dereference at virtual address 00000000000001a2

    <snip>

    pc : dev_pm_domain_detach+0x8/0x48
    lr : camss_probe+0x374/0x9c0

    <snip>

    Call trace:
     dev_pm_domain_detach+0x8/0x48
     platform_probe+0x70/0xf0
     really_probe+0xc4/0x2a8
     __driver_probe_device+0x80/0x140
     driver_probe_device+0x48/0x170
     __device_attach_driver+0xc0/0x148
     bus_for_each_drv+0x88/0xf0
     __device_attach+0xb0/0x1c0
     device_initial_probe+0x1c/0x30
     bus_probe_device+0xb4/0xc0
     deferred_probe_work_func+0x90/0xd0
     process_one_work+0x164/0x3e0
     worker_thread+0x310/0x420
     kthread+0x120/0x130
     ret_from_fork+0x10/0x20
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:23:22.380Z
CVE-2024-56583 sched/deadline: Fix warning in migrate_enable for boosted tasks
In the Linux kernel, the following vulnerability has been resolved:

sched/deadline: Fix warning in migrate_enable for boosted tasks

When running the following command:

while true; do
    stress-ng --cyclic 30 --timeout 30s --minimize --quiet
done

a warning is eventually triggered:

WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794
setup_new_dl_entity+0x13e/0x180
...
Call Trace:
 <TASK>
 ? show_trace_log_lvl+0x1c4/0x2df
 ? enqueue_dl_entity+0x631/0x6e0
 ? setup_new_dl_entity+0x13e/0x180
 ? __warn+0x7e/0xd0
 ? report_bug+0x11a/0x1a0
 ? handle_bug+0x3c/0x70
 ? exc_invalid_op+0x14/0x70
 ? asm_exc_invalid_op+0x16/0x20
 enqueue_dl_entity+0x631/0x6e0
 enqueue_task_dl+0x7d/0x120
 __do_set_cpus_allowed+0xe3/0x280
 __set_cpus_allowed_ptr_locked+0x140/0x1d0
 __set_cpus_allowed_ptr+0x54/0xa0
 migrate_enable+0x7e/0x150
 rt_spin_unlock+0x1c/0x90
 group_send_sig_info+0xf7/0x1a0
 ? kill_pid_info+0x1f/0x1d0
 kill_pid_info+0x78/0x1d0
 kill_proc_info+0x5b/0x110
 __x64_sys_kill+0x93/0xc0
 do_syscall_64+0x5c/0xf0
 entry_SYSCALL_64_after_hwframe+0x6e/0x76
 RIP: 0033:0x7f0dab31f92b

This warning occurs because set_cpus_allowed dequeues and enqueues tasks
with the ENQUEUE_RESTORE flag set. If the task is boosted, the warning
is triggered. A boosted task already had its parameters set by
rt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary,
hence the WARN_ON call.

Check if we are requeueing a boosted task and avoid calling
setup_new_dl_entity if that's the case.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:50:51.781Z
CVE-2024-56584 io_uring/tctx: work around xa_store() allocation error issue
In the Linux kernel, the following vulnerability has been resolved:

io_uring/tctx: work around xa_store() allocation error issue

syzbot triggered the following WARN_ON:

WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51

which is the

WARN_ON_ONCE(!xa_empty(&tctx->xa));

sanity check in __io_uring_free() when a io_uring_task is going through
its final put. The syzbot test case includes injecting memory allocation
failures, and it very much looks like xa_store() can fail one of its
memory allocations and end up with ->head being non-NULL even though no
entries exist in the xarray.

Until this issue gets sorted out, work around it by attempting to
iterate entries in our xarray, and WARN_ON_ONCE() if one is found.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:50:52.735Z
CVE-2024-56586 f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.
In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.

creating a large files during checkpoint disable until it runs out of
space and then delete it, then remount to enable checkpoint again, and
then unmount the filesystem triggers the f2fs_bug_on as below:

------------[ cut here ]------------
kernel BUG at fs/f2fs/inode.c:896!
CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:f2fs_evict_inode+0x58c/0x610
Call Trace:
 __die_body+0x15/0x60
 die+0x33/0x50
 do_trap+0x10a/0x120
 f2fs_evict_inode+0x58c/0x610
 do_error_trap+0x60/0x80
 f2fs_evict_inode+0x58c/0x610
 exc_invalid_op+0x53/0x60
 f2fs_evict_inode+0x58c/0x610
 asm_exc_invalid_op+0x16/0x20
 f2fs_evict_inode+0x58c/0x610
 evict+0x101/0x260
 dispose_list+0x30/0x50
 evict_inodes+0x140/0x190
 generic_shutdown_super+0x2f/0x150
 kill_block_super+0x11/0x40
 kill_f2fs_super+0x7d/0x140
 deactivate_locked_super+0x2a/0x70
 cleanup_mnt+0xb3/0x140
 task_work_run+0x61/0x90

The root cause is: creating large files during disable checkpoint
period results in not enough free segments, so when writing back root
inode will failed in f2fs_enable_checkpoint. When umount the file
system after enabling checkpoint, the root inode is dirty in
f2fs_evict_inode function, which triggers BUG_ON. The steps to
reproduce are as follows:

dd if=/dev/zero of=f2fs.img bs=1M count=55
mount f2fs.img f2fs_dir -o checkpoint=disable:10%
dd if=/dev/zero of=big bs=1M count=50
sync
rm big
mount -o remount,checkpoint=enable f2fs_dir
umount f2fs_dir

Let's redirty inode when there is not free segments during checkpoint
is disable.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:50:54.378Z
CVE-2024-56590 Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packet
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packet

This fixes not checking if skb really contains an ACL header otherwise
the code may attempt to access some uninitilized/invalid memory past the
valid skb->data.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:50:57.854Z
CVE-2024-56591 Bluetooth: hci_conn: Use disable_delayed_work_sync
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_conn: Use disable_delayed_work_sync

This makes use of disable_delayed_work_sync instead
cancel_delayed_work_sync as it not only cancel the ongoing work but also
disables new submit which is disarable since the object holding the work
is about to be freed.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:50:58.674Z
CVE-2024-56593 wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()
In the Linux kernel, the following vulnerability has been resolved:

wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()

This patch fixes a NULL pointer dereference bug in brcmfmac that occurs
when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs
are sent from the pkt queue.

The problem is the number of entries in the pre-allocated sgtable, it is
nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1.
Given the default [rt]xglom_size=32 it's actually 35 which is too small.
Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB
is added for each original SKB if tailroom isn't enough to hold tail_pad.
At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"
in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return
NULL and this causes the oops.

The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle
the worst-case.
Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464
additional bytes of memory.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:00.466Z
CVE-2024-56595 jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree
In the Linux kernel, the following vulnerability has been resolved:

jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree

When the value of lp is 0 at the beginning of the for loop, it will
become negative in the next assignment and we should bail out.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:02.371Z
CVE-2024-56596 jfs: fix array-index-out-of-bounds in jfs_readdir
In the Linux kernel, the following vulnerability has been resolved:

jfs: fix array-index-out-of-bounds in jfs_readdir

The stbl might contain some invalid values. Added a check to
return error code in that case.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:03.282Z
CVE-2024-56597 jfs: fix shift-out-of-bounds in dbSplit
In the Linux kernel, the following vulnerability has been resolved:

jfs: fix shift-out-of-bounds in dbSplit

When dmt_budmin is less than zero, it causes errors
in the later stages. Added a check to return an error beforehand
in dbAllocCtl itself.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:04.184Z
CVE-2024-56598 jfs: array-index-out-of-bounds fix in dtReadFirst
In the Linux kernel, the following vulnerability has been resolved:

jfs: array-index-out-of-bounds fix in dtReadFirst

The value of stbl can be sometimes out of bounds due
to a bad filesystem. Added a check with appopriate return
of error code in that case.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:04.988Z
CVE-2024-56599 wifi: ath10k: avoid NULL pointer error during sdio remove
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath10k: avoid NULL pointer error during sdio remove

When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio
workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON
is set to yes, kernel panic will happen:
Call trace:
 destroy_workqueue+0x1c/0x258
 ath10k_sdio_remove+0x84/0x94
 sdio_bus_remove+0x50/0x16c
 device_release_driver_internal+0x188/0x25c
 device_driver_detach+0x20/0x2c

This is because during 'rmmod ath10k', ath10k_sdio_remove() will call
ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()
will finally be called in ath10k_core_destroy(). This function will free
struct cfg80211_registered_device *rdev and all its members, including
wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio
workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.

After device release, destroy_workqueue() will use NULL pointer then the
kernel panic happen.

Call trace:
ath10k_sdio_remove
  ->ath10k_core_unregister
    ……
    ->ath10k_core_stop
      ->ath10k_hif_stop
        ->ath10k_sdio_irq_disable
    ->ath10k_hif_power_down
      ->del_timer_sync(&ar_sdio->sleep_timer)
  ->ath10k_core_destroy
    ->ath10k_mac_destroy
      ->ieee80211_free_hw
        ->wiphy_free
    ……
          ->wiphy_dev_release
  ->destroy_workqueue

Need to call destroy_workqueue() before ath10k_core_destroy(), free
the work queue buffer first and then free pointer of work queue by
ath10k_core_destroy(). This order matches the error path order in
ath10k_sdio_probe().

No work will be queued on sdio workqueue between it is destroyed and
ath10k_core_destroy() is called. Based on the call_stack above, the
reason is:
Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and
ath10k_sdio_irq_disable() will queue work on sdio workqueue.
Sleep timer will be deleted before ath10k_core_destroy() in
ath10k_hif_power_down().
ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().
ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif
bus, so ath10k_sdio_hif_tx_sg() won't be called anymore.

Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:05.866Z
CVE-2024-56600 net: inet6: do not leave a dangling sk pointer in inet6_create()
In the Linux kernel, the following vulnerability has been resolved:

net: inet6: do not leave a dangling sk pointer in inet6_create()

sock_init_data() attaches the allocated sk pointer to the provided sock
object. If inet6_create() fails later, the sk object is released, but the
sock object retains the dangling sk pointer, which may cause use-after-free
later.

Clear the sock sk pointer on error.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:06.610Z
CVE-2024-56601 net: inet: do not leave a dangling sk pointer in inet_create()
In the Linux kernel, the following vulnerability has been resolved:

net: inet: do not leave a dangling sk pointer in inet_create()

sock_init_data() attaches the allocated sk object to the provided sock
object. If inet_create() fails later, the sk object is freed, but the
sock object retains the dangling pointer, which may create use-after-free
later.

Clear the sk pointer in the sock object on error.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:07.358Z
CVE-2024-56602 net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()
In the Linux kernel, the following vulnerability has been resolved:

net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()

sock_init_data() attaches the allocated sk object to the provided sock
object. If ieee802154_create() fails later, the allocated sk object is
freed, but the dangling pointer remains in the provided sock object, which
may allow use-after-free.

Clear the sk pointer in the sock object on error.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:08.174Z
CVE-2024-56603 net: af_can: do not leave a dangling sk pointer in can_create()
In the Linux kernel, the following vulnerability has been resolved:

net: af_can: do not leave a dangling sk pointer in can_create()

On error can_create() frees the allocated sk object, but sock_init_data()
has already attached it to the provided sock object. This will leave a
dangling sk pointer in the sock object and may cause use-after-free later.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:08.923Z
CVE-2024-56604 Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()

bt_sock_alloc() attaches allocated sk object to the provided sock object.
If rfcomm_dlc_alloc() fails, we release the sk object, but leave the
dangling pointer in the sock object, which may cause use-after-free.

Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:09.618Z
CVE-2024-56605 Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()

bt_sock_alloc() allocates the sk object and attaches it to the provided
sock object. On error l2cap_sock_alloc() frees the sk object, but the
dangling pointer is still attached to the sock object, which may create
use-after-free in other code.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:10.344Z
CVE-2024-56606 af_packet: avoid erroring out after sock_init_data() in packet_create()
In the Linux kernel, the following vulnerability has been resolved:

af_packet: avoid erroring out after sock_init_data() in packet_create()

After sock_init_data() the allocated sk object is attached to the provided
sock object. On error, packet_create() frees the sk object leaving the
dangling pointer in the sock object on return. Some other code may try
to use this pointer and cause use-after-free.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-12-27T14:51:11.327Z