huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-52006: git: Newline confusion in credential helpers can lead to credential exfiltration in git
Component: git
Severity: Low
CWE: CWE-140 (Improper Neutralization of Delimiters)
CVSS v3: 4.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N)
Public date: 2025-01-14T18:39:52.748000+00:00

A flaw was found in Git. Git defines a line-based protocol that is used to exchange information between Git and Git credential helpers. Some ecosystems, most notably .NET and node.js, interpret single Carriage Return characters as newlines, which render the protections against CVE-2020-5260 incomplete for credential helpers, which has the potential to expose stored credentials to malicious URLs.


Affected upstream versions: <= 2.40.3, >= 2.41.0, <= 2.41.2, >= 2.42.0, <= 2.42.3, >= 2.43.0, <= 2.43.5, >= 2.44.0, <= 2.44.2, >= 2.45.0, <= 2.45.2, >= 2.46.0, <= 2.46.2, >= 2.47.0, < 2.47.2, = 2.48.0
Fixed upstream versions: v2.40.4
Upstream repository: https://github.com/git/git
Upstream fix commit: b01b9b81d36759cdcd07305e78765199e1bc2060
CVE-2024-52011: launch-editor: vite: launch-editor: Arbitrary command execution via insufficient file argument sanitization
Component: launch-editor
Severity: Important
CWE: CWE-88 (Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))
CVSS v3: 8.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L)
Public date: 2026-06-01T17:17:43.792000+00:00

A flaw was found in launch-editor, a tool that allows users to open files with line numbers in an editor from Node.js. Due to insufficient sanitization of the `file` argument in the `launchEditor` function, an attacker can execute arbitrary commands on Windows systems by supplying a filename that contains special characters. This can lead to a complete compromise of the affected system.


Affected upstream versions: < 2.9.0, < 5.4.9
Fixed upstream versions: v2.9.0
Upstream repository: https://github.com/vitejs/launch-editor
Upstream fix commit: 971291e8a6a91226e1616c5c0ec85423d2d50a5e
CVE-2024-52304: aiohttp: aiohttp vulnerable to request smuggling due to incorrect parsing of chunk extensions
Component: aiohttp
Severity: Moderate
CWE: CWE-444 (Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling'))
CVSS v3: 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N)
Public date: 2024-11-18T20:12:48.612000+00:00

A flaw was found in the aiohttp package. The Python parser parses newlines in chunk extensions incorrectly, which can lead to request smuggling vulnerabilities under certain conditions. If a pure Python version of aiohttp is installed, for example, without the usual C extensions, or `AIOHTTP_NO_EXTENSIONS` is enabled, an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections.


Affected upstream versions: < 3.10.11
Fixed upstream versions: v3.10.11
Upstream repository: https://github.com/aio-libs/aiohttp
Upstream fix commit: 259edc369075de63e6f3a4eaade058c62af0df71
CVE-2024-52332: kernel: igb: Fix potential invalid memory access in igb_init_module()
Component: kernel
Severity: Moderate
CWE: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-01-11T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

igb: Fix potential invalid memory access in igb_init_module()

The pci_register_driver() can fail and when this happened, the dca_notifier
needs to be unregistered, otherwise the dca_notifier can be called when
igb fails to install, resulting to invalid memory access.

Statement: Bug could happen during error path and during device registration. The security impact is limited.

Affected upstream versions: 2.6.29
Fixed upstream versions: 0, 5.10.231, 5.15.174, 5.4.287, 6.1.120, 6.12.5, 6.13, 6.6.66
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4458046617dfadc351162dbaea1945c57eebdf36
CVE-2024-52798: path-to-regexp: path-to-regexp Unpatched `path-to-regexp` ReDoS in 0.1.x
Component: path-to-regexp
Severity: Moderate
CWE: CWE-1333 (Inefficient Regular Expression Complexity)
CVSS v3: 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L)
Public date: 2024-12-05T22:45:42.774000+00:00

A flaw was found in path-to-regexp. A path-to-regexp turns path strings into regular expressions. In certain cases, path-to-regexp will output a regular expression that can be exploited to cause poor performance.

Statement: This vulnerability exists because of an incomplete fix for CVE-2024-45296.

Affected upstream versions: < 0.1.12
Fixed upstream versions: v0.1.12
Upstream repository: https://github.com/pillarjs/path-to-regexp
Upstream fix commit: f01c26a013b1889f0c217c643964513acf17f6a4
CVE-2024-52804: python-tornado: Tornado has HTTP cookie parsing DoS vulnerability
Component: python-tornado
Severity: Important
CWE: CWE-1333 (Inefficient Regular Expression Complexity)
CVSS v3: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-22T15:43:38.572000+00:00

A flaw was found in Tornado's HTTP cookie parsing algorithm. This vulnerability allows excessive CPU consumption via maliciously crafted cookie headers due to Quadratic complexity, potentially blocking the processing of other requests and leading to the loss of availability of the system.


Affected upstream versions: < 6.4.2
Fixed upstream versions: v6.4.2
Upstream repository: https://github.com/tornadoweb/tornado
Upstream fix commit: d5ba4a1695fbf7c6a3e54313262639b198291533
CVE-2024-53042: kernel: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()
Component: kernel
Severity: Moderate
CWE: CWE-662 (Improper Synchronization)
CVSS v3: 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
Public date: 2024-11-19T00:00:00+00:00

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 upstream versions: 5.10.227 < 5.10.229, 5.15.168 < 5.15.171, 5.18
Fixed upstream versions: 0, 5.10.229, 5.15.171, 6.1.116, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e2742758c9c85c84e077ede5f916479f724e11c2
CVE-2024-53044: kernel: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()
Component: kernel
Severity: Moderate
CWE: CWE-672 (Operation on a Resource after Expiration or Release)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

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 upstream versions: 6.8
Fixed upstream versions: 0, 6.11.7, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8966eb69a143b1c032365fe84f2815f3c46f2590
CVE-2024-53047: kernel: mptcp: init: protect sched with rcu_read_lock
Component: kernel
Severity: Low
CWE: CWE-667 (Improper Locking)
CVSS v3: 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
Public date: 2024-11-19T00:00:00+00:00

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 upstream versions: 6.6
Fixed upstream versions: 0, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: cb8b81ad3e893a6d18dcdd3754cc2ea2a42c0136
CVE-2024-53050: kernel: drm/i915/hdcp: Add encoder check in hdcp2_get_capability
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

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 upstream versions: 6.7
Fixed upstream versions: 0, 6.11.7, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5b89dcf23575eb5bb95ce8d672cbc2232c2eb096
CVE-2024-53051: kernel: drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability
Component: kernel
Severity: Low
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

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 upstream versions: 5.0
Fixed upstream versions: 0, 6.11.7, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4912e8fb3c37fb2dedf48d9c18bbbecd70e720f8
CVE-2024-53052: kernel: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write
Component: kernel
Severity: Moderate
CWE: CWE-667 (Improper Locking)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

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 upstream versions: 5.1
Fixed upstream versions: 0, 5.10.230, 5.15.172, 6.1.116, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 485d9232112b17f389b29497ff41b97b3189546b
CVE-2024-53055: kernel: wifi: iwlwifi: mvm: fix 6 GHz scan construction
Component: kernel
Severity: Moderate
CWE: CWE-835 (Loop with Unreachable Exit Condition ('Infinite Loop'))
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

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 upstream versions: 5.11
Fixed upstream versions: 0, 5.15.171, 6.1.116, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2ac15e5a8f42fed5d90ed9e1197600913678c50f
CVE-2024-53057: kernel: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-11-19T00:00:00+00:00

A flaw was found in the packet scheduler API in the Linux kernel. An invalid assumption about qdiscs with major handle ffff allows qdiscs, such as DRR, that maintain an active class list to cause a use-after-free with a dangling class pointer.

Statement: This issue can only be exploited by an attacker with admin or root privileges, limiting the impact of this flaw. For this reason, this vulnerability has been rated with a Moderate severity.

Affected upstream versions: 2.6.25
Fixed upstream versions: 0, 4.19.323, 5.10.229, 5.15.171, 5.4.285, 6.1.116, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e7f9a6f97eb067599a74f3bcb6761976b0ed303e
CVE-2024-53059: kernel: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()
Component: kernel
Severity: Moderate
CWE: CWE-460 (Improper Cleanup on Thrown Exception)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-11-19T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()

1. The size of the response packet is not validated.
2. The response buffer is not freed.

Resolve these issues by switching to iwl_mvm_send_cmd_status(),
which handles both size validation and frees the buffer.

Statement: The bug could happen if Intel Wireless WiFi MVM Firmware being used and as result of hardware failure and malicious data during auto-recovery (IWL_MVM_STATUS_IN_HW_RESTART, iwl_mvm_send_recovery_cmd). The security impact is limited, because only local privileged user can trigger it.

Affected upstream versions: 5.1
Fixed upstream versions: 0, 5.10.229, 5.15.171, 5.4.285, 6.1.116, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9c98ee7ea463a838235e7a0e35851b38476364f2
CVE-2024-53060: kernel: drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported

acpi_evaluate_object() may return AE_NOT_FOUND (failure), which
would result in dereferencing buffer.pointer (obj) while being NULL.

Although this case may be unrealistic for the current code, it is
still better to protect against possible bugs.

Bail out also when status is AE_NOT_FOUND.

This fixes 1 FORWARD_NULL issue reported by Coverity
Report: CID 1600951:  Null pointer dereferences  (FORWARD_NULL)

(cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1)


Affected upstream versions: 4.19.323 < 4.19.324, 5.4.285 < 5.4.286, 5.10.229 < 5.10.230, 5.15.170 < 5.15.172, 6.1.115 < 6.1.117, 6.6.59 < 6.6.61, 6.11.6 < 6.11.8
Fixed upstream versions: 4.19.324, 5.10.230, 5.15.172, 5.4.286, 6.1.117, 6.11.8, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ce8a00a00e36f61f5a1e47734332420b68784c43
CVE-2024-53064: kernel: idpf: fix idpf_vc_core_init error path
Component: kernel
Severity: Low
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

idpf: fix idpf_vc_core_init error path

In an event where the platform running the device control plane
is rebooted, reset is detected on the driver. It releases
all the resources and waits for the reset to complete. Once the
reset is done, it tries to build the resources back. At this
time if the device control plane is not yet started, then
the driver timeouts on the virtchnl message and retries to
establish the mailbox again.

In the retry flow, mailbox is deinitialized but the mailbox
workqueue is still alive and polling for the mailbox message.
This results in accessing the released control queue leading to
null-ptr-deref. Fix it by unrolling the work queue cancellation
and mailbox deinitialization in the reverse order which they got
initialized.


Affected upstream versions: 6.7
Fixed upstream versions: 0, 6.11.8, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 683fcd90ba22507ebeb1921a26dfe77efff8c266
CVE-2024-53070: kernel: usb: dwc3: fix fault at system suspend if device was already runtime suspended
Component: kernel
Severity: Moderate
CWE: CWE-664 (Improper Control of a Resource Through its Lifetime)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-19T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: fix fault at system suspend if device was already runtime suspended

If the device was already runtime suspended then during system suspend
we cannot access the device registers else it will crash.

Also we cannot access any registers after dwc3_core_exit() on some
platforms so move the dwc3_enable_susphy() call to the top.


Affected upstream versions: 5.15.170 < 5.15.172, 6.1.115 < 6.1.117, 6.6.59 < 6.6.61, 6.11.5 < 6.11.8
Fixed upstream versions: 5.15.172, 6.1.117, 6.11.8, 6.6.61
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d9e65d461a9de037e7c9d584776d025cfce6d86d