deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-35900
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: reject new basechain after table flag update

When dormant flag is toggled, hooks are disabled in the commit phase by
iterating over current chains in table (existing and new).

The following configuration allows for an inconsistent state:

  add table x
  add chain x y { type filter hook input priority 0; }
  add table x { flags dormant; }
  add chain x w { type filter hook input priority 1; }

which triggers the following warning when trying to unregister chain w
which is already unregistered.

[  127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50                                                                     1 __nf_unregister_net_hook+0x21a/0x260
[...]
[  127.322519] Call Trace:
[  127.322521]  <TASK>
[  127.322524]  ? __warn+0x9f/0x1a0
[  127.322531]  ? __nf_unregister_net_hook+0x21a/0x260
[  127.322537]  ? report_bug+0x1b1/0x1e0
[  127.322545]  ? handle_bug+0x3c/0x70
[  127.322552]  ? exc_invalid_op+0x17/0x40
[  127.322556]  ? asm_exc_invalid_op+0x1a/0x20
[  127.322563]  ? kasan_save_free_info+0x3b/0x60
[  127.322570]  ? __nf_unregister_net_hook+0x6a/0x260
[  127.322577]  ? __nf_unregister_net_hook+0x21a/0x260
[  127.322583]  ? __nf_unregister_net_hook+0x6a/0x260
[  127.322590]  ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables]
[  127.322655]  nft_table_disable+0x75/0xf0 [nf_tables]
[  127.322717]  nf_tables_commit+0x2571/0x2620 [nf_tables]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/41bad13c0e8a5a2b47a7472cced922555372daab; https://git.kernel.org/stable/c/420132bee3d0136b7fba253a597b098fe15493a7; https://git.kernel.org/stable/c/6d12f21f8bbe23fde25b77c2bf5973c136b8bef8
CVE: CVE-2024-35901
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

net: mana: Fix Rx DMA datasize and skb_over_panic

mana_get_rxbuf_cfg() aligns the RX buffer's DMA datasize to be
multiple of 64. So a packet slightly bigger than mtu+14, say 1536,
can be received and cause skb_over_panic.

Sample dmesg:
[ 5325.237162] skbuff: skb_over_panic: text:ffffffffc043277a len:1536 put:1536 head:ff1100018b517000 data:ff1100018b517100 tail:0x700 end:0x6ea dev:<NULL>
[ 5325.243689] ------------[ cut here ]------------
[ 5325.245748] kernel BUG at net/core/skbuff.c:192!
[ 5325.247838] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 5325.258374] RIP: 0010:skb_panic+0x4f/0x60
[ 5325.302941] Call Trace:
[ 5325.304389]  <IRQ>
[ 5325.315794]  ? skb_panic+0x4f/0x60
[ 5325.317457]  ? asm_exc_invalid_op+0x1f/0x30
[ 5325.319490]  ? skb_panic+0x4f/0x60
[ 5325.321161]  skb_put+0x4e/0x50
[ 5325.322670]  mana_poll+0x6fa/0xb50 [mana]
[ 5325.324578]  __napi_poll+0x33/0x1e0
[ 5325.326328]  net_rx_action+0x12e/0x280

As discussed internally, this alignment is not necessary. To fix
this bug, remove it from the code. So oversized packets will be
marked as CQE_RX_TRUNCATED by NIC, and dropped.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/05cb7c41fa1a7a7b2c2a6b81bbe7c67f5c11932b; https://git.kernel.org/stable/c/c0de6ab920aafb56feab56058e46b688e694a246; https://git.kernel.org/stable/c/ca58927b00385005f488b6a9905ced7a4f719aad
CVE: CVE-2024-35902
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

net/rds: fix possible cp null dereference

cp might be null, calling cp->cp_conn would produce null dereference

[Simon Horman adds:]

Analysis:

* cp is a parameter of __rds_rdma_map and is not reassigned.

* The following call-sites pass a NULL cp argument to __rds_rdma_map()

  - rds_get_mr()
  - rds_get_mr_for_dest

* Prior to the code above, the following assumes that cp may be NULL
  (which is indicative, but could itself be unnecessary)

	trans_private = rs->rs_transport->get_mr(
		sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL,
		args->vec.addr, args->vec.bytes,
		need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);

* The code modified by this patch is guarded by IS_ERR(trans_private),
  where trans_private is assigned as per the previous point in this analysis.

  The only implementation of get_mr that I could locate is rds_ib_get_mr()
  which can return an ERR_PTR if the conn (4th) argument is NULL.

* ret is set to PTR_ERR(trans_private).
  rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.
  Thus ret may be -ENODEV in which case the code in question will execute.

Conclusion:
* cp may be NULL at the point where this patch adds a check;
  this patch does seem to address a possible bug
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/62fc3357e079a07a22465b9b6ef71bb6ea75ee4b; https://git.kernel.org/stable/c/6794090c742008c53b344b35b021d4a3093dc50a; https://git.kernel.org/stable/c/92309bed3c5fbe2ccd4c45056efd42edbd06162d
CVE: CVE-2024-35903
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/bpf: Fix IP after emitting call depth accounting

Adjust the IP passed to `emit_patch` so it calculates the correct offset
for the CALL instruction if `x86_call_depth_emit_accounting` emits code.
Otherwise we will skip some instructions and most likely crash.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3f9d57c771656bfd651e22edcfdb5f60e62542d4; https://git.kernel.org/stable/c/81166178cf0a0062a22b1b3b5368183d39577028; https://git.kernel.org/stable/c/9d98aa088386aee3db1b7b60b800c0fde0654a4a
CVE: CVE-2024-35904
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

selinux: avoid dereference of garbage after mount failure

In case kern_mount() fails and returns an error pointer return in the
error branch instead of continuing and dereferencing the error pointer.

While on it drop the never read static variable selinuxfs_mount.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/37801a36b4d68892ce807264f784d818f8d0d39b; https://git.kernel.org/stable/c/477ed6789eb9f3f4d3568bb977f90c863c12724e; https://git.kernel.org/stable/c/68784a5d01b8868ff85a7926676b6729715fff3c
CVE: CVE-2024-35905
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Protect against int overflow for stack access size

This patch re-introduces protection against the size of access to stack
memory being negative; the access size can appear negative as a result
of overflowing its signed int representation. This should not actually
happen, as there are other protections along the way, but we should
protect against it anyway. One code path was missing such protections
(fixed in the previous patch in the series), causing out-of-bounds array
accesses in check_stack_range_initialized(). This patch causes the
verification of a program with such a non-sensical access size to fail.

This check used to exist in a more indirect way, but was inadvertendly
removed in a833a17aeac7.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129, CWE-190
References: https://git.kernel.org/stable/c/203a68151e8eeb331d4a64ab78303f3a15faf103; https://git.kernel.org/stable/c/37dc1718dc0c4392dbfcb9adec22a776e745dd69; https://git.kernel.org/stable/c/3f0784b2f1eb9147973d8c43ba085c5fdf44ff69
CVE: CVE-2024-35906
Published: 2024-05-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-35908
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

tls: get psock ref after taking rxlock to avoid leak

At the start of tls_sw_recvmsg, we take a reference on the psock, and
then call tls_rx_reader_lock. If that fails, we return directly
without releasing the reference.

Instead of adding a new label, just take the reference after locking
has succeeded, since we don't need it before.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/30fabe50a7ace3e9d57cf7f9288f33ea408491c8; https://git.kernel.org/stable/c/417e91e856099e9b8a42a2520e2255e6afe024be; https://git.kernel.org/stable/c/b565d294e3d5aa809566a4d819835da11997d8b3
CVE: CVE-2024-35910
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

tcp: properly terminate timers for kernel sockets

We had various syzbot reports about tcp timers firing after
the corresponding netns has been dismantled.

Fortunately Josef Bacik could trigger the issue more often,
and could test a patch I wrote two years ago.

When TCP sockets are closed, we call inet_csk_clear_xmit_timers()
to 'stop' the timers.

inet_csk_clear_xmit_timers() can be called from any context,
including when socket lock is held.
This is the reason it uses sk_stop_timer(), aka del_timer().
This means that ongoing timers might finish much later.

For user sockets, this is fine because each running timer
holds a reference on the socket, and the user socket holds
a reference on the netns.

For kernel sockets, we risk that the netns is freed before
timer can complete, because kernel sockets do not hold
reference on the netns.

This patch adds inet_csk_clear_xmit_timers_sync() function
that using sk_stop_timer_sync() to make sure all timers
are terminated before the kernel socket is released.
Modules using kernel sockets close them in their netns exit()
handler.

Also add sock_not_owned_by_me() helper to get LOCKDEP
support : inet_csk_clear_xmit_timers_sync() must not be called
while socket lock is held.

It is very possible we can revert in the future commit
3a58f13a881e ("net: rds: acquire refcount on TCP sockets")
which attempted to solve the issue in rds only.
(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)

We probably can remove the check_net() tests from
tcp_out_of_resources() and __tcp_close() in the future.
CVSS Score: 5.8 (MEDIUM)
References: https://git.kernel.org/stable/c/151c9c724d05d5b0dd8acd3e11cb69ef1f2dbada; https://git.kernel.org/stable/c/2e43d8eba6edd1cf05a3a20fdd77688fa7ec16a4; https://git.kernel.org/stable/c/44e62f5d[PII_REDACTED]4afd47c6a421ad30772e7f
CVE: CVE-2024-35912
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: rfi: fix potential response leaks

If the rx payload length check fails, or if kmemdup() fails,
we still need to free the command response. Fix that.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/06a093807eb7b5c5b29b6cff49f8174a4e702341; https://git.kernel.org/stable/c/28db0ae86cb91a4ab0e855cff779daead936b7d5; https://git.kernel.org/stable/c/99a75d75007421d8e08ba139e24f77395cd08f62
CVE: CVE-2024-35913
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: pick the version of SESSION_PROTECTION_NOTIF

When we want to know whether we should look for the mac_id or the
link_id in struct iwl_mvm_session_prot_notif, we should look at the
version of SESSION_PROTECTION_NOTIF.

This causes WARNINGs:

WARNING: CPU: 0 PID: 11403 at drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:959 iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm]
RIP: 0010:iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm]
Code: 00 49 c7 84 24 48 07 00 00 00 00 00 00 41 c6 84 24 78 07 00 00 ff 4c 89 f7 e8 e9 71 54 d9 e9 7d fd ff ff 0f 0b e9 23 fe ff ff <0f> 0b e9 1c fe ff ff 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffb4bb00003d40 EFLAGS: 00010202
RAX: [PII_REDACTED] RBX: ffff9ae63a361000 RCX: ffff9ae4a98b60d4
RDX: ffff9ae4588499c0 RSI: [PII_REDACTED] RDI: ffff9ae4a98b6358
RBP: ffffb4bb00003d68 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: ffffb4bb00003d00 R11:[PII_REDACTED]00000f R12: ffff9ae441399050
R13: ffff9ae4761329e8 R14: [PII_REDACTED] R15: [PII_REDACTED]
FS:  [PII_REDACTED](0000) GS:ffff9ae7af400000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 000055fb75680018 CR3: 00000003dae32006 CR4:[PII_REDACTED]f70ef0
PKRU: 55555554
Call Trace:
 <IRQ>
 ? show_regs+0x69/0x80
 ? __warn+0x8d/0x150
 ? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm]
 ? report_bug+0x196/0x1c0
 ? handle_bug+0x45/0x80
 ? exc_invalid_op+0x1c/0xb0
 ? asm_exc_invalid_op+0x1f/0x30
 ? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm]
 iwl_mvm_rx_common+0x115/0x340 [iwlmvm]
 iwl_mvm_rx_mq+0xa6/0x100 [iwlmvm]
 iwl_pcie_rx_handle+0x263/0xa10 [iwlwifi]
 iwl_pcie_napi_poll_msix+0x32/0xd0 [iwlwifi]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/222abd95f503e28c0404e596291fe472fe90929c; https://git.kernel.org/stable/c/bbe806c294c9c4cd1221140d96e5f367673e393a; https://git.kernel.org/stable/c/222abd95f503e28c0404e596291fe472fe90929c
CVE: CVE-2024-35914
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

nfsd: Fix error cleanup path in nfsd_rename()

Commit a8b0026847b8 ("rename(): avoid a deadlock in the case of parents
having no common ancestor") added an error bail out path. However this
path does not drop the remount protection that has been acquired. Fix
the cleanup path to properly drop the remount protection.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/331e125e02c08ffaecc1074af78a988a278039bd; https://git.kernel.org/stable/c/9fe6e9e7b[PII_REDACTED][PII_REDACTED]c17cfde1c56; https://git.kernel.org/stable/c/331e125e02c08ffaecc1074af78a988a278039bd
CVE: CVE-2024-35915
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet

syzbot reported the following uninit-value access issue [1][2]:

nci_rx_work() parses and processes received packet. When the payload
length is zero, each message type handler reads uninitialized payload
and KMSAN detects this issue. The receipt of a packet with a zero-size
payload is considered unexpected, and therefore, such packets should be
silently discarded.

This patch resolved this issue by checking payload size before calling
each message type handler codes.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff; https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240; https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c
CVE: CVE-2024-35916
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

dma-buf: Fix NULL pointer dereference in sanitycheck()

If due to a memory allocation failure mock_chain() returns NULL, it is
passed to dma_fence_enable_sw_signaling() resulting in NULL pointer
dereference there.

Call dma_fence_enable_sw_signaling() only if mock_chain() succeeds.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/[PII_REDACTED]cdab0c65e99e4cdd47c4606debe14e; https://git.kernel.org/stable/c/156c226cbbdcf5f3bce7b2408a33b59fab7fae2c; https://git.kernel.org/stable/c/2295bd846765c766701e666ed2e4b35396be25e6
CVE: CVE-2024-35917
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/bpf: Fix bpf_plt pointer arithmetic

Kui-Feng Lee reported a crash on s390x triggered by the
dummy_st_ops/dummy_init_ptr_arg test [1]:

  [<[PII_REDACTED]>] 0x2
  [<[PII_REDACTED]9d5cde>] bpf_struct_ops_test_run+0x156/0x250
  [<[PII_REDACTED]33145a>] __sys_bpf+0xa1a/0xd00
  [<[PII_REDACTED]3319dc>] __s390x_sys_bpf+0x44/0x50
  [<[PII_REDACTED]c4382c>] __do_syscall+0x244/0x300
  [<[PII_REDACTED]c59a40>] system_call+0x70/0x98

This is caused by GCC moving memcpy() after assignments in
bpf_jit_plt(), resulting in NULL pointers being written instead of
the return and the target addresses.

Looking at the GCC internals, the reordering is allowed because the
alias analysis thinks that the memcpy() destination and the assignments'
left-hand-sides are based on different objects: new_plt and
bpf_plt_ret/bpf_plt_target respectively, and therefore they cannot
alias.

This is in turn due to a violation of the C standard:

  When two pointers are subtracted, both shall point to elements of the
  same array object, or one past the last element of the array object
  ...

From the C's perspective, bpf_plt_ret and bpf_plt are distinct objects
and cannot be subtracted. In the practical terms, doing so confuses the
GCC's alias analysis.

The code was written this way in order to let the C side know a few
offsets defined in the assembly. While nice, this is by no means
necessary. Fix the noncompliance by hardcoding these offsets.

[1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/7ded842b356d151ece8ac[PII_REDACTED]e6d3998bb; https://git.kernel.org/stable/c/c3062bdb859b6e2567e7f5c8cde20c0250bb130f; https://git.kernel.org/stable/c/d3d74e45a060d218fe4b0c9174f0a77517509d8e
CVE: CVE-2023-52699
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

sysv: don't call sb_bread() with pointers_lock held

syzbot is reporting sleep in atomic context in SysV filesystem [1], for
sb_bread() is called with rw_spinlock held.

A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug
and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by
"Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.

Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the
former bug by moving pointers_lock lock to the callers, but instead
introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made
this problem easier to hit).

Al Viro suggested that why not to do like get_branch()/get_block()/
find_shared() in Minix filesystem does. And doing like that is almost a
revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()
 from with find_shared() is called without write_lock(&pointers_lock).
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76; https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f; https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09
CVE: CVE-2024-35918
Published: 2024-05-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-35919
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: adding lock to protect encoder context list

Add a lock for the ctx_list, to avoid accessing a NULL pointer
within the 'vpu_enc_ipi_handler' function when the ctx_list has
been deleted due to an unexpected behavior on the SCP IP block.
CVSS Score: 7.0 (HIGH)
CWE: CWE-476
References: https://git.kernel.org/stable/c/41671f0c0182b2bae74ca7e3b0f155559e3e2fc5; https://git.kernel.org/stable/c/51c84a8aac6e3b59af2b0e92ba63cabe2e641a2d; https://git.kernel.org/stable/c/afaaf3a0f647a24a7bf6a2145d8ade37baaf75ad
CVE: CVE-2024-35920
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: adding lock to protect decoder context list

Add a lock for the ctx_list, to avoid accessing a NULL pointer
within the 'vpu_dec_ipi_handler' function when the ctx_list has
been deleted due to an unexpected behavior on the SCP IP block.

Hardware name: Google juniper sku16 board (DT)
pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--)
pc : vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec]
lr : scp_ipi_handler+0xd0/0x194 [mtk_scp]
sp : ffffffc0131dbbd0
x29: ffffffc0131dbbd0 x28: [PII_REDACTED]
x27: ffffff9bb277f348 x26: ffffff9bb242ad00
x25: ffffffd2d440d3b8 x24: ffffffd2a13ff1d4
x23: ffffff9bb7fe85a0 x22: ffffffc0133fbdb0
x21: [PII_REDACTED] x20: ffffff9b050ea328
x19: ffffffc0131dbc08 x18: [PII_REDACTED]
x17: [PII_REDACTED] x16: ffffffd2d461c6e0
x15: [PII_REDACTED] x14:[PII_REDACTED]00018f
x13:[PII_REDACTED]00004d x12: [PII_REDACTED]
x11: [PII_REDACTED] x10: fffffffffffffff0
x9 : ffffff9bb6e793a8 x8 : [PII_REDACTED]
x7 : [PII_REDACTED] x6 :[PII_REDACTED]00003f
x5 : [PII_REDACTED] x4 : fffffffffffffff0
x3 : [PII_REDACTED] x2 : ffffff9bb6e79080
x1 : [PII_REDACTED] x0 : ffffffc0131dbc08
Call trace:
vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec (HASH:6c3f 2)]
scp_ipi_handler+0xd0/0x194 [mtk_scp (HASH:7046 3)]
mt8183_scp_irq_handler+0x44/0x88 [mtk_scp (HASH:7046 3)]
scp_irq_handler+0x48/0x90 [mtk_scp (HASH:7046 3)]
irq_thread_fn+0x38/0x94
irq_thread+0x100/0x1c0
kthread+0x140/0x1fc
ret_from_fork+0x10/0x30
Code: 54000088 f94ca50a eb14015f 54000060 (f9400108)
---[ end trace ace43ce36cbd5c93 ]---
Kernel panic - not syncing: Oops: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: 0x12c4000000 from 0xffffffc010000000
PHYS_OFFSET: 0xffffffe580000000
CPU features: 0x08240002,2188200c
Memory Limit: none
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0a2dc707aa42214f9c4827bd57e344e29a0841d6; https://git.kernel.org/stable/c/23aaf824121055ba81b55f75444355bd83c8eb38; https://git.kernel.org/stable/c/6467cda18c9f9b5f2f9a0aa1e2861c653e41f382
CVE: CVE-2024-35921
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: Fix oops when HEVC init fails

The stateless HEVC decoder saves the instance pointer in the context
regardless if the initialization worked or not. This caused a use after
free, when the pointer is freed in case of a failure in the deinit
function.
Only store the instance pointer when the initialization was successful,
to solve this issue.

 Hardware name: Acer Tomato (rev3 - 4) board (DT)
 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]
 lr : vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]
 sp : ffff80008750bc20
 x29: ffff80008750bc20 x28: ffff1299f6d70000 x27: [PII_REDACTED]
 x26: [PII_REDACTED] x25: [PII_REDACTED] x24: [PII_REDACTED]
 x23: ffff80008750bc98 x22:[PII_REDACTED]00a003 x21: ffffd45c4cfae000
 x20: [PII_REDACTED] x19: ffff1299fd668310 x18:[PII_REDACTED]00001a
 x17:[PII_REDACTED]44ffff x16: ffffd45cb15dc648 x15: [PII_REDACTED]
 x14: ffff1299c08da1c0 x13: ffffd45cb1f87a10 x12: ffffd45cb2f5fe80
 x11: [PII_REDACTED] x10:[PII_REDACTED]001b30 x9 : ffffd45c4d12b488
 x8 : 1fffe25339380d81 x7 : [PII_REDACTED] x6 : ffff1299c9c06c00
 x5 : [PII_REDACTED] x4 : [PII_REDACTED] x3 : [PII_REDACTED]
 x2 : [PII_REDACTED] x1 : ffff80008750bc98 x0 : [PII_REDACTED]
 Call trace:
  vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]
  vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]
  vpu_dec_deinit+0x1c/0x30 [mtk_vcodec_dec]
  vdec_hevc_slice_deinit+0x30/0x98 [mtk_vcodec_dec]
  vdec_if_deinit+0x38/0x68 [mtk_vcodec_dec]
  mtk_vcodec_dec_release+0x20/0x40 [mtk_vcodec_dec]
  fops_vcodec_release+0x64/0x118 [mtk_vcodec_dec]
  v4l2_release+0x7c/0x100
  __fput+0x80/0x2d8
  __fput_sync+0x58/0x70
  __arm64_sys_close+0x40/0x90
  invoke_syscall+0x50/0x128
  el0_svc_common.constprop.0+0x48/0xf0
  do_el0_svc+0x24/0x38
  el0_svc+0x38/0xd8
  el0t_64_sync_handler+0xc0/0xc8
  el0t_64_sync+0x1a8/0x1b0
 Code: d503201f f9401660 b900127f b900227f (f9400400)
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/521ce0ea7418298d754494fe53263c23c4c78a8e; https://git.kernel.org/stable/c/97c75ee5de060d271d80109b0c47cb6008439e5b; https://git.kernel.org/stable/c/ec25fc3c2c1e8958a51abcfed614f81446d918c4
CVE: CVE-2024-35922
Published: 2024-05-19
Description: In the Linux kernel, the following vulnerability has been resolved:

fbmon: prevent division by zero in fb_videomode_from_videomode()

The expression htotal * vtotal can have a zero value on
overflow. It is necessary to prevent division by zero like in
fb_var_to_videomode().

Found by Linux Verification Center (linuxtesting.org) with Svace.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/1b107d637fed68a787da77a3514ad06e57abd0b4; https://git.kernel.org/stable/c/1fb52bc1de55e9e0bdf71fe078efd4da0889710f; https://git.kernel.org/stable/c/3d4b909704bf2114f64f87363fa22b5ef8ac4a33