rainbutterfly/cve_corpus huggingface dataset:
CVE-2024-53029 Improper Input Validation in Automotive OS Platform
Memory corruption while reading a value from a buffer controlled by the Guest Virtual Machine.
Problem types: cwe_id: CWE-20
description: CWE-20 Improper Input Validation
Affected products: vendor: Qualcomm, Inc.
product: Snapdragon
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: HIGH
baseScore: 7.8
baseSeverity: HIGH
confidentialityImpact: HIGH
integrityImpact: HIGH
privilegesRequired: LOW
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
version: 3.1
Published: 2025-03-03T10:07:43.190Z
CVE-2024-53030 Improper Input Validation in Automotive OS Platform
Memory corruption while processing input message passed from FE driver.
Problem types: cwe_id: CWE-20
description: CWE-20 Improper Input Validation
Affected products: vendor: Qualcomm, Inc.
product: Snapdragon
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: HIGH
baseScore: 7.8
baseSeverity: HIGH
confidentialityImpact: HIGH
integrityImpact: HIGH
privilegesRequired: LOW
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
version: 3.1
Published: 2025-03-03T10:07:44.376Z
CVE-2024-53031 Improper Input Validation in Automotive OS Platform
Memory corruption while reading a type value from a buffer controlled by the Guest Virtual Machine.
Problem types: cwe_id: CWE-20
description: CWE-20 Improper Input Validation
Affected products: vendor: Qualcomm, Inc.
product: Snapdragon
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: HIGH
baseScore: 7.8
baseSeverity: HIGH
confidentialityImpact: HIGH
integrityImpact: HIGH
privilegesRequired: LOW
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
version: 3.1
Published: 2025-03-03T10:07:45.524Z
CVE-2024-53032 Time-of-check Time-of-use (TOCTOU) Race Condition in Automotive OS Platform
Memory corruption may occur in keyboard virtual device due to guest VM interaction.
Problem types: cwe_id: CWE-367
description: CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition
Affected products: vendor: Qualcomm, Inc.
product: Snapdragon
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: HIGH
baseScore: 7.8
baseSeverity: HIGH
confidentialityImpact: HIGH
integrityImpact: HIGH
privilegesRequired: LOW
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
version: 3.1
Published: 2025-03-03T10:07:46.637Z
CVE-2024-53033 Untrusted Pointer Dereference in DSP_Services
Memory corruption while doing Escape call when user provides valid kernel address in the place of valid user buffer address.
Problem types: cwe_id: CWE-822
description: CWE-822 Untrusted Pointer Dereference
Affected products: vendor: Qualcomm, Inc.
product: Snapdragon
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: HIGH
baseScore: 7.8
baseSeverity: HIGH
confidentialityImpact: HIGH
integrityImpact: HIGH
privilegesRequired: LOW
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
version: 3.1
Published: 2025-03-03T10:07:47.750Z
CVE-2024-53034 Untrusted Pointer Dereference in DSP_Services
Memory corruption occurs during an Escape call if an invalid Kernel Mode CPU event and sync object handle are passed with the DriverKnownEscape flag reset.
Problem types: cwe_id: CWE-822
description: CWE-822 Untrusted Pointer Dereference
Affected products: vendor: Qualcomm, Inc.
product: Snapdragon
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: HIGH
baseScore: 7.8
baseSeverity: HIGH
confidentialityImpact: HIGH
integrityImpact: HIGH
privilegesRequired: LOW
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
version: 3.1
Published: 2025-03-03T10:07:48.882Z
CVE-2024-53041 
A vulnerability has been identified in Teamcenter Visualization V14.2 (All versions < V14.2.0.14), Teamcenter Visualization V14.3 (All versions < V14.3.0.12), Teamcenter Visualization V2312 (All versions < V2312.0008), Tecnomatix Plant Simulation V2302 (All versions < V2302.0016), Tecnomatix Plant Simulation V2404 (All versions < V2404.0005). The affected applications contain a stack based overflow vulnerability while parsing specially crafted WRL files.
This could allow an attacker to execute code in the context of the current process. (ZDI-CAN-25000)
Problem types: cwe_id: CWE-121
description: CWE-121: Stack-based Buffer Overflow
Affected products: vendor: Siemens
product: Teamcenter Visualization V14.2
default_status: unknown
vendor: Siemens
product: Teamcenter Visualization V14.3
default_status: unknown
vendor: Siemens
product: Teamcenter Visualization V2312
default_status: unknown
vendor: Siemens
product: Tecnomatix Plant Simulation V2302
default_status: unknown
vendor: Siemens
product: Tecnomatix Plant Simulation V2404
default_status: unknown
CVSS v3.1: version: 3.1
vectorString: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
baseScore: 7.8
baseSeverity: HIGH
Published: 2024-12-10T13:54:12.113Z
CVE-2024-53042 ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()
In the Linux kernel, the following vulnerability has been resolved:

ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()

There are code paths from which the function is called without holding
the RCU read lock, resulting in a suspicious RCU usage warning [1].

Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire
the RCU read lock before calling
l3mdev_master_upper_ifindex_by_index_rcu().

[1]
WARNING: suspicious RCU usage
6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted
-----------------------------
net/core/dev.c:876 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
1 lock held by ip/361:
 #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60

stack backtrace:
CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Call Trace:
 <TASK>
 dump_stack_lvl+0xba/0x110
 lockdep_rcu_suspicious.cold+0x4f/0xd6
 dev_get_by_index_rcu+0x1d3/0x210
 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0
 ip_tunnel_bind_dev+0x72f/0xa00
 ip_tunnel_newlink+0x368/0x7a0
 ipgre_newlink+0x14c/0x170
 __rtnl_newlink+0x1173/0x19c0
 rtnl_newlink+0x6c/0xa0
 rtnetlink_rcv_msg+0x3cc/0xf60
 netlink_rcv_skb+0x171/0x450
 netlink_unicast+0x539/0x7f0
 netlink_sendmsg+0x8c1/0xd80
 ____sys_sendmsg+0x8f9/0xc20
 ___sys_sendmsg+0x197/0x1e0
 __sys_sendmsg+0x122/0x1f0
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:30.854Z
CVE-2024-53043 mctp i2c: handle NULL header address
In the Linux kernel, the following vulnerability has been resolved:

mctp i2c: handle NULL header address

daddr can be NULL if there is no neighbour table entry present,
in that case the tx packet should be dropped.

saddr will usually be set by MCTP core, but check for NULL in case a
packet is transmitted by a different protocol.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:31.497Z
CVE-2024-53044 net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()
In the Linux kernel, the following vulnerability has been resolved:

net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()

This command:

$ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact
Error: block dev insert failed: -EBUSY.

fails because user space requests the same block index to be set for
both ingress and egress.

[ side note, I don't think it even failed prior to commit 913b47d3424e
  ("net/sched: Introduce tc block netdev tracking infra"), because this
  is a command from an old set of notes of mine which used to work, but
  alas, I did not scientifically bisect this ]

The problem is not that it fails, but rather, that the second time
around, it fails differently (and irrecoverably):

$ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact
Error: dsa_core: Flow block cb is busy.

[ another note: the extack is added by me for illustration purposes.
  the context of the problem is that clsact_init() obtains the same
  &q->ingress_block pointer as &q->egress_block, and since we call
  tcf_block_get_ext() on both of them, "dev" will be added to the
  block->ports xarray twice, thus failing the operation: once through
  the ingress block pointer, and once again through the egress block
  pointer. the problem itself is that when xa_insert() fails, we have
  emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the
  offload never sees a corresponding FLOW_BLOCK_UNBIND. ]

Even correcting the bad user input, we still cannot recover:

$ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact
Error: dsa_core: Flow block cb is busy.

Basically the only way to recover is to reboot the system, or unbind and
rebind the net device driver.

To fix the bug, we need to fill the correct error teardown path which
was missed during code movement, and call tcf_block_offload_unbind()
when xa_insert() fails.

[ last note, fundamentally I blame the label naming convention in
  tcf_block_get_ext() for the bug. The labels should be named after what
  they do, not after the error path that jumps to them. This way, it is
  obviously wrong that two labels pointing to the same code mean
  something is wrong, and checking the code correctness at the goto site
  is also easier ]
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:32.095Z
CVE-2024-53045 ASoC: dapm: fix bounds checker error in dapm_widget_list_create
In the Linux kernel, the following vulnerability has been resolved:

ASoC: dapm: fix bounds checker error in dapm_widget_list_create

The widgets array in the snd_soc_dapm_widget_list has a __counted_by
attribute attached to it, which points to the num_widgets variable. This
attribute is used in bounds checking, and if it is not set before the
array is filled, then the bounds sanitizer will issue a warning or a
kernel panic if CONFIG_UBSAN_TRAP is set.

This patch sets the size of the widgets list calculated with
list_for_each as the initial value for num_widgets as it is used for
allocating memory for the array. It is updated with the actual number of
added elements after the array is filled.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:32.718Z
CVE-2024-53047 mptcp: init: protect sched with rcu_read_lock
In the Linux kernel, the following vulnerability has been resolved:

mptcp: init: protect sched with rcu_read_lock

Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT
creates this splat when an MPTCP socket is created:

  =============================
  WARNING: suspicious RCU usage
  6.12.0-rc2+ #11 Not tainted
  -----------------------------
  net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!

  other info that might help us debug this:

  rcu_scheduler_active = 2, debug_locks = 1
  no locks held by mptcp_connect/176.

  stack backtrace:
  CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  Call Trace:
   <TASK>
   dump_stack_lvl (lib/dump_stack.c:123)
   lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)
   mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7))
   mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1))
   ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28)
   inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386)
   ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1))
   __sock_create (net/socket.c:1576)
   __sys_socket (net/socket.c:1671)
   ? __pfx___sys_socket (net/socket.c:1712)
   ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1))
   __x64_sys_socket (net/socket.c:1728)
   do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1))
   entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

That's because when the socket is initialised, rcu_read_lock() is not
used despite the explicit comment written above the declaration of
mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the
warning.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:34.036Z
CVE-2024-53048 ice: fix crash on probe for DPLL enabled E810 LOM
In the Linux kernel, the following vulnerability has been resolved:

ice: fix crash on probe for DPLL enabled E810 LOM

The E810 Lan On Motherboard (LOM) design is vendor specific. Intel
provides the reference design, but it is up to vendor on the final
product design. For some cases, like Linux DPLL support, the static
values defined in the driver does not reflect the actual LOM design.
Current implementation of dpll pins is causing the crash on probe
of the ice driver for such DPLL enabled E810 LOM designs:

WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330
...
Call Trace:
 <TASK>
 ? __warn+0x83/0x130
 ? dpll_pin_get+0x2c4/0x330
 ? report_bug+0x1b7/0x1d0
 ? handle_bug+0x42/0x70
 ? exc_invalid_op+0x18/0x70
 ? asm_exc_invalid_op+0x1a/0x20
 ? dpll_pin_get+0x117/0x330
 ? dpll_pin_get+0x2c4/0x330
 ? dpll_pin_get+0x117/0x330
 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice]
...

The number of dpll pins enabled by LOM vendor is greater than expected
and defined in the driver for Intel designed NICs, which causes the crash.

Prevent the crash and allow generic pin initialization within Linux DPLL
subsystem for DPLL enabled E810 LOM designs.

Newly designed solution for described issue will be based on "per HW
design" pin initialization. It requires pin information dynamically
acquired from the firmware and is already in progress, planned for
next-tree only.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:34.654Z
CVE-2024-53049 slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof
In the Linux kernel, the following vulnerability has been resolved:

slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof

'modprobe slub_kunit' will have a warning as shown below. The root cause
is that __kmalloc_cache_noprof was directly used, which resulted in no
alloc_tag being allocated. This caused current->alloc_tag to be null,
leading to a warning in alloc_tag_add_check.

Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically
within lib/slub_kunit.c, which is the only user of this internal slub
function outside kmalloc implementation itself.

[58162.947016] WARNING: CPU: 2 PID: 6210 at
./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c
[58162.957721] Call trace:
[58162.957919]  alloc_tagging_slab_alloc_hook+0x268/0x27c
[58162.958286]  __kmalloc_cache_noprof+0x14c/0x344
[58162.958615]  test_kmalloc_redzone_access+0x50/0x10c [slub_kunit]
[58162.959045]  kunit_try_run_case+0x74/0x184 [kunit]
[58162.959401]  kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit]
[58162.959841]  kthread+0x10c/0x118
[58162.960093]  ret_from_fork+0x10/0x20
[58162.960363] ---[ end trace 0000000000000000 ]---
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:35.260Z
CVE-2024-53050 drm/i915/hdcp: Add encoder check in hdcp2_get_capability
In the Linux kernel, the following vulnerability has been resolved:

drm/i915/hdcp: Add encoder check in hdcp2_get_capability

Add encoder check in intel_hdcp2_get_capability to avoid
null pointer error.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:35.857Z
CVE-2024-53051 drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability
In the Linux kernel, the following vulnerability has been resolved:

drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability

Sometimes during hotplug scenario or suspend/resume scenario encoder is
not always initialized when intel_hdcp_get_capability add
a check to avoid kernel null pointer dereference.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:36.456Z
CVE-2024-53052 io_uring/rw: fix missing NOWAIT check for O_DIRECT start write
In the Linux kernel, the following vulnerability has been resolved:

io_uring/rw: fix missing NOWAIT check for O_DIRECT start write

When io_uring starts a write, it'll call kiocb_start_write() to bump the
super block rwsem, preventing any freezes from happening while that
write is in-flight. The freeze side will grab that rwsem for writing,
excluding any new writers from happening and waiting for existing writes
to finish. But io_uring unconditionally uses kiocb_start_write(), which
will block if someone is currently attempting to freeze the mount point.
This causes a deadlock where freeze is waiting for previous writes to
complete, but the previous writes cannot complete, as the task that is
supposed to complete them is blocked waiting on starting a new write.
This results in the following stuck trace showing that dependency with
the write blocked starting a new write:

task:fio             state:D stack:0     pid:886   tgid:886   ppid:876
Call trace:
 __switch_to+0x1d8/0x348
 __schedule+0x8e8/0x2248
 schedule+0x110/0x3f0
 percpu_rwsem_wait+0x1e8/0x3f8
 __percpu_down_read+0xe8/0x500
 io_write+0xbb8/0xff8
 io_issue_sqe+0x10c/0x1020
 io_submit_sqes+0x614/0x2110
 __arm64_sys_io_uring_enter+0x524/0x1038
 invoke_syscall+0x74/0x268
 el0_svc_common.constprop.0+0x160/0x238
 do_el0_svc+0x44/0x60
 el0_svc+0x44/0xb0
 el0t_64_sync_handler+0x118/0x128
 el0t_64_sync+0x168/0x170
INFO: task fsfreeze:7364 blocked for more than 15 seconds.
      Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963

with the attempting freezer stuck trying to grab the rwsem:

task:fsfreeze        state:D stack:0     pid:7364  tgid:7364  ppid:995
Call trace:
 __switch_to+0x1d8/0x348
 __schedule+0x8e8/0x2248
 schedule+0x110/0x3f0
 percpu_down_write+0x2b0/0x680
 freeze_super+0x248/0x8a8
 do_vfs_ioctl+0x149c/0x1b18
 __arm64_sys_ioctl+0xd0/0x1a0
 invoke_syscall+0x74/0x268
 el0_svc_common.constprop.0+0x160/0x238
 do_el0_svc+0x44/0x60
 el0_svc+0x44/0xb0
 el0t_64_sync_handler+0x118/0x128
 el0t_64_sync+0x168/0x170

Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a
blocking grab of the super block rwsem if it isn't set. For normal issue
where IOCB_NOWAIT would always be set, this returns -EAGAIN which will
have io_uring core issue a blocking attempt of the write. That will in
turn also get completions run, ensuring forward progress.

Since freezing requires CAP_SYS_ADMIN in the first place, this isn't
something that can be triggered by a regular user.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:37.067Z
CVE-2024-53053 scsi: ufs: core: Fix another deadlock during RTC update
In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Fix another deadlock during RTC update

If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count
is 0, we will enter the runtime suspend callback.  However, the runtime
suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock.

Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the
deadlock.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:37.653Z
CVE-2024-53055 wifi: iwlwifi: mvm: fix 6 GHz scan construction
In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: fix 6 GHz scan construction

If more than 255 colocated APs exist for the set of all
APs found during 2.4/5 GHz scanning, then the 6 GHz scan
construction will loop forever since the loop variable
has type u8, which can never reach the number found when
that's bigger than 255, and is stored in a u32 variable.
Also move it into the loops to have a smaller scope.

Using a u32 there is fine, we limit the number of APs in
the scan list and each has a limit on the number of RNR
entries due to the frame size. With a limit of 1000 scan
results, a frame size upper bound of 4096 (really it's
more like ~2300) and a TBTT entry size of at least 11,
we get an upper bound for the number of ~372k, well in
the bounds of a u32.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:39.037Z
CVE-2024-53056 drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()
In the Linux kernel, the following vulnerability has been resolved:

drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()

In mtk_crtc_create(), if the call to mbox_request_channel() fails then we
set the "mtk_crtc->cmdq_client.chan" pointer to NULL.  In that situation,
we do not call cmdq_pkt_create().

During the cleanup, we need to check if the "mtk_crtc->cmdq_client.chan"
is NULL first before calling cmdq_pkt_destroy().  Calling
cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and
it will result in a NULL pointer dereference.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:39.646Z
CVE-2024-53057 net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT
In the Linux kernel, the following vulnerability has been resolved:

net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT

In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed
to be either root or ingress. This assumption is bogus since it's valid
to create egress qdiscs with major handle ffff:
Budimir Markovic found that for qdiscs like DRR that maintain an active
class list, it will cause a UAF with a dangling class pointer.

In 066a3b5b2346, the concern was to avoid iterating over the ingress
qdisc since its parent is itself. The proper fix is to stop when parent
TC_H_ROOT is reached because the only way to retrieve ingress is when a
hierarchy which does not contain a ffff: major handle call into
qdisc_lookup with TC_H_MAJ(TC_H_ROOT).

In the scenario where major ffff: is an egress qdisc in any of the tree
levels, the updates will also propagate to TC_H_ROOT, which then the
iteration must stop.


 net/sched/sch_api.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-11-19T17:19:40.284Z