deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-40957
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

seg6: fix parameter passing when calling NF_HOOK() in End.DX4 and End.DX6 behaviors

input_action_end_dx4() and input_action_end_dx6() are called NF_HOOK() for
PREROUTING hook, in PREROUTING hook, we should passing a valid indev,
and a NULL outdev to NF_HOOK(), otherwise may trigger a NULL pointer
dereference, as below:

    [74830.647293] BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
    [74830.655633] #PF: supervisor read access in kernel mode
    [74830.657888] #PF: error_code(0x0000) - not-present page
    [74830.659500] PGD 0 P4D 0
    [74830.660450] Oops: 0000 [#1] PREEMPT SMP PTI
    ...
    [74830.664953] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    [74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter]
    ...
    [74830.689725] Call Trace:
    [74830.690402]  <IRQ>
    [74830.690953]  ? show_trace_log_lvl+0x1c4/0x2df
    [74830.692020]  ? show_trace_log_lvl+0x1c4/0x2df
    [74830.693095]  ? ipt_do_table+0x286/0x710 [ip_tables]
    [74830.694275]  ? __die_body.cold+0x8/0xd
    [74830.695205]  ? page_fault_oops+0xac/0x140
    [74830.696244]  ? exc_page_fault+0x62/0x150
    [74830.697225]  ? asm_exc_page_fault+0x22/0x30
    [74830.698344]  ? rpfilter_mt+0x44/0x15e [ipt_rpfilter]
    [74830.699540]  ipt_do_table+0x286/0x710 [ip_tables]
    [74830.700758]  ? ip6_route_input+0x19d/0x240
    [74830.701752]  nf_hook_slow+0x3f/0xb0
    [74830.702678]  input_action_end_dx4+0x19b/0x1e0
    [74830.703735]  ? input_action_end_t+0xe0/0xe0
    [74830.704734]  seg6_local_input_core+0x2d/0x60
    [74830.705782]  lwtunnel_input+0x5b/0xb0
    [74830.706690]  __netif_receive_skb_one_core+0x63/0xa0
    [74830.707825]  process_backlog+0x99/0x140
    [74830.709538]  __napi_poll+0x2c/0x160
    [74830.710673]  net_rx_action+0x296/0x350
    [74830.711860]  __do_softirq+0xcb/0x2ac
    [74830.713049]  do_softirq+0x63/0x90

input_action_end_dx4() passing a NULL indev to NF_HOOK(), and finally
trigger a NULL dereference in rpfilter_mt()->rpfilter_is_loopback():

    static bool
    rpfilter_is_loopback(const struct sk_buff *skb,
          	       const struct net_device *in)
    {
            // in is NULL
            return skb->pkt_type == PACKET_LOOPBACK ||
          	 in->flags & IFF_LOOPBACK;
    }
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/561475d53aa7e4511ee7cdba8728ded81cf1db1c; https://git.kernel.org/stable/c/9a3bc8d16e0aacd65c31aaf23a2bced3288a7779; https://git.kernel.org/stable/c/af90e3d73dc45778767b2fb6e7edd57ebe34380d
CVE: CVE-2024-40959
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()

ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.

syzbot reported:

Oops: general protection fault, probably for non-canonical address 0xdffffc[PII_REDACTED]: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000000-0x[PII_REDACTED]000007]
CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker
 RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64
Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00
RSP: 0018:ffffc[PII_REDACTED]8 EFLAGS: 00010246
RAX: dffffc[PII_REDACTED] RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7
RDX: [PII_REDACTED] RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98
RBP: ffff88807ad73248 R08: [PII_REDACTED] R09: fffffffffffff000
R10: ffff88807b079dc0 R11: [PII_REDACTED] R12: ffffc[PII_REDACTED]0
R13: [PII_REDACTED] R14: [PII_REDACTED] R15: [PII_REDACTED]
FS:  [PII_REDACTED](0000) GS:ffff8880b9300000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007f4586d00440 CR3: [PII_REDACTED] CR4:[PII_REDACTED]3506f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
  xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]
  xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]
  xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541
  xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835
  xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]
  xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201
  xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]
  xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309
  ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256
  send6+0x611/0xd20 drivers/net/wireguard/socket.c:139
  wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178
  wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200
  wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40
  wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51
  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
  process_scheduled_works kernel/workqueue.c:3312 [inline]
  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
  kthread+0x2c1/0x3a0 kernel/kthread.c:389
  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/20427b85781aca0ad072851f6907a3d4b2fed8d1; https://git.kernel.org/stable/c/600a62b4232ac027f788c3ca395bc2333adeaacf; https://git.kernel.org/stable/c/83c02fb2cc0afee5bb53cddf3f34f045f654ad6a
CVE: CVE-2024-40960
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: prevent possible NULL dereference in rt6_probe()

syzbot caught a NULL dereference in rt6_probe() [1]

Bail out if  __in6_dev_get() returns NULL.

[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000658-0x[PII_REDACTED]00065f]
CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
 RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]
 RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758
Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19
RSP: 0018:ffffc900034af070 EFLAGS: 00010203
RAX: dffffc[PII_REDACTED] RBX: [PII_REDACTED] RCX: ffffc[PII_REDACTED]0
RDX:[PII_REDACTED]0000cb RSI: ffffffff8990d0cd RDI:[PII_REDACTED]00065c
RBP: ffffc900034af150 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12:[PII_REDACTED]00000a
R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: [PII_REDACTED]
FS:  00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4:[PII_REDACTED]3506f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
  rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784
  nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496
  __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825
  find_rr_leaf net/ipv6/route.c:853 [inline]
  rt6_select net/ipv6/route.c:897 [inline]
  fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195
  ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231
  pol_lookup_func include/net/ip6_fib.h:616 [inline]
  fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121
  ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]
  ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651
  ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147
  ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250
  rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898
  inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg net/socket.c:745 [inline]
  sock_write_iter+0x4b8/0x5c0 net/socket.c:1160
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0x6b6/0x1140 fs/read_write.c:590
  ksys_write+0x1f8/0x260 fs/read_write.c:643
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1ed9849fdf9a1a617129346b11d2094ca26828dc; https://git.kernel.org/stable/c/51ee2f7c30790799d0ec30c0ce0c743e58f046f2; https://git.kernel.org/stable/c/569c9d9ea6648d099187527b93982f406ddcebc0
CVE: CVE-2024-40961
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: prevent possible NULL deref in fib6_nh_init()

syzbot reminds us that in6_dev_get() can return NULL.

fib6_nh_init()
    ip6_validate_gw(  &idev  )
        ip6_route_check_nh(  idev  )
            *idev = in6_dev_get(dev); // can be NULL

Oops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x[PII_REDACTED]0005e0-0x[PII_REDACTED]0005e7]
CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
 RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606
Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b
RSP: 0018:ffffc900032775a0 EFLAGS: 00010202
RAX:[PII_REDACTED]0000bc RBX:[PII_REDACTED]0005e0 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: ffffc90003277a54 RDI: ffff88802b3a08d8
RBP: ffffc900032778b0 R08:[PII_REDACTED]0002fc R09: [PII_REDACTED]
R10:[PII_REDACTED]0002fc R11: [PII_REDACTED] R12: ffff88802b3a08b8
R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc[PII_REDACTED]
FS:  00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: [PII_REDACTED] CR3:[PII_REDACTED]5e8000 CR4:[PII_REDACTED]3506f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
  ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809
  ip6_route_add+0x28/0x160 net/ipv6/route.c:3853
  ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483
  inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579
  sock_do_ioctl+0x158/0x460 net/socket.c:1222
  sock_ioctl+0x629/0x8e0 net/socket.c:1341
  vfs_ioctl fs/ioctl.c:51 [inline]
  __do_sys_ioctl fs/ioctl.c:907 [inline]
  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f940f07cea9
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2eab4543a2204092c3a7af81d7d6c506e59a03a6; https://git.kernel.org/stable/c/3200ffeec4d59aad5bc9ca75d2c1fae47c0aeade; https://git.kernel.org/stable/c/4cdfe813015d5a24586bd0a84fa0fa6eb0a1f668
CVE: CVE-2024-40963
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

mips: bmips: BCM6358: make sure CBR is correctly set

It was discovered that some device have CBR address set to 0 causing
kernel panic when arch_sync_dma_for_cpu_all is called.

This was notice in situation where the system is booted from TP1 and
BMIPS_GET_CBR() returns 0 instead of a valid address and
!!(read_c0_brcm_cmt_local() & (1 << 31)); not failing.

The current check whether RAC flush should be disabled or not are not
enough hence lets check if CBR is a valid address or not.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-754
References: https://git.kernel.org/stable/c/10afe5f7d30f6fe50c2b1177549d0e04921fc373; https://git.kernel.org/stable/c/2cd4854ef14a487bcfb76c[PII_REDACTED]cad27b52; https://git.kernel.org/stable/c/36d771ce6028b886e18a4a8956a5d23688e4e13d
CVE: CVE-2024-40964
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind()

The cs35l41_hda_unbind() function clears the hda_component entry
matching it's index and then dereferences the codec pointer held in the
first element of the hda_component array, this is an issue when the
device index was 0.

Instead use the codec pointer stashed in the cs35l41_hda structure as it
will still be valid.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/19be722369c347f3af1c5848e303980ed040b819; https://git.kernel.org/stable/c/6386682cdc8b41319c92fbbe421953e33a28840c; https://git.kernel.org/stable/c/ff27bd8e17884f7cdefecb3f3817caadd6813dc0
CVE: CVE-2024-40965
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

i2c: lpi2c: Avoid calling clk_get_rate during transfer

Instead of repeatedly calling clk_get_rate for each transfer, lock
the clock rate and cache the value.
A deadlock has been observed while adding tlv320aic32x4 audio codec to
the system. When this clock provider adds its clock, the clk mutex is
locked already, it needs to access i2c, which in return needs the mutex
for clk_get_rate as well.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/2b42e9587a7a9c7b824e0feb92958f258263963e; https://git.kernel.org/stable/c/4268254a39484fc11ba991ae148bacbe75d9cc0a; https://git.kernel.org/stable/c/d038693e08adf9c162c[PII_REDACTED]e4f5a2df045
CVE: CVE-2024-40966
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

tty: add the option to have a tty reject a new ldisc

... and use it to limit the virtual terminals to just N_TTY.  They are
kind of special, and in particular, the "con_write()" routine violates
the "writes cannot sleep" rule that some ldiscs rely on.

This avoids the

   BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659

when N_GSM has been attached to a virtual console, and gsmld_write()
calls con_write() while holding a spinlock, and con_write() then tries
to get the console lock.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/287b569a5b914903ba7c438a3c0dbc3410ebb409; https://git.kernel.org/stable/c/3c6332f3bb1578b5b10ac2561247b1d6272ae937; https://git.kernel.org/stable/c/5920ac19964f9e20181f63b410d9200ddbf8dc86
CVE: CVE-2024-40967
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: imx: Introduce timeout when waiting on transmitter empty

By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential
deadlock.

In case of the timeout, there is not much we can do, so we simply ignore
the transmitter state and optimistically try to continue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/53b2c95547427c358f45515a9f144efee95e3701; https://git.kernel.org/stable/c/7f2b9ab6d0b26f16cd38dd9fd91d51899635f7c7; https://git.kernel.org/stable/c/7f9e70c68b7ace0141fe3bc94bf7b61296b71916
CVE: CVE-2024-40968
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

MIPS: Octeon: Add PCIe link status check

The standard PCIe configuration read-write interface is used to
access the configuration space of the peripheral PCIe devices
of the mips processor after the PCIe link surprise down, it can
generate kernel panic caused by "Data bus error". So it is
necessary to add PCIe link status check for system protection.
When the PCIe link is down or in training, assigning a value
of 0 to the configuration address can prevent read-write behavior
to the configuration space of peripheral PCIe devices, thereby
preventing kernel panic.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-754
References: https://git.kernel.org/stable/c/1c33fd17383f48f679186c54df78542106deeaa0; https://git.kernel.org/stable/c/25998f5613159fe35920dbd484fcac7ea3ad0799; https://git.kernel.org/stable/c/29b83a64df3b42c88c0338696feb6fdcd7f1f3b7
CVE: CVE-2024-40969
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: don't set RO when shutting down f2fs

Shutdown does not check the error of thaw_super due to readonly, which
causes a deadlock like below.

f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC)        issue_discard_thread
 - bdev_freeze
  - freeze_super
 - f2fs_stop_checkpoint()
  - f2fs_handle_critical_error                     - sb_start_write
    - set RO                                         - waiting
 - bdev_thaw
  - thaw_super_locked
    - return -EINVAL, if sb_rdonly()
 - f2fs_stop_discard_thread
  -> wait for kthread_stop(discard_thread);
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a; https://git.kernel.org/stable/c/3bdb7f161697e2d5123b89fe1778ef17a44858e7; https://git.kernel.org/stable/c/f47ed3b284b38f235355e281f57dfa8fffcc6563
CVE: CVE-2024-40970
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

Avoid hw_desc array overrun in dw-axi-dmac

I have a use case where nr_buffers = 3 and in which each descriptor is composed by 3
segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put()
handles the hw_desc considering the descs_allocated, this scenario would result in a
kernel panic (hw_desc array will be overrun).

To fix this, the proposal is to add a new member to the axi_dma_desc structure,
where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it in
axi_desc_put() to handle the hw_desc array correctly.

Additionally I propose to remove the axi_chan_start_first_queued() call after completing
the transfer, since it was identified that unbalance can occur (started descriptors can
be interrupted and transfer ignored due to DMA channel not being enabled).
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/333e11bf47fa8d477db90e2900b1ed3c9ae9b697; https://git.kernel.org/stable/c/7c3bb96a20cd8db3b8824b2ff08b6cde4505c7e5; https://git.kernel.org/stable/c/9004784e8d68bcd1ac1376407ba296fa28f04dbe
CVE: CVE-2024-40971
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: remove clear SB_INLINECRYPT flag in default_options

In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.
If create new file or open file during this gap, these files
will not use inlinecrypt. Worse case, it may lead to data
corruption if wrappedkey_v0 is enable.

Thread A:                               Thread B:

-f2fs_remount				-f2fs_file_open or f2fs_new_inode
  -default_options
	<- clear SB_INLINECRYPT flag

                                          -fscrypt_select_encryption_impl

  -parse_options
	<- set SB_INLINECRYPT again
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/38a82c8d00638bb642bef787eb1d5e0e4d3b7d71; https://git.kernel.org/stable/c/724429db09e21ee153fef35e34342279d33df6ae; https://git.kernel.org/stable/c/a9cea0489c562c97cd56bb345e78939f9909e7f4
CVE: CVE-2024-40972
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: do not create EA inode under buffer lock

ext4_xattr_set_entry() creates new EA inodes while holding buffer lock
on the external xattr block. This is problematic as it nests all the
allocation locking (which acquires locks on other buffers) under the
buffer lock. This can even deadlock when the filesystem is corrupted and
e.g. quota file is setup to contain xattr block as data block. Move the
allocation of EA inode out of ext4_xattr_set_entry() into the callers.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0752e7fb549d90c33b4d4186f11cfd25a556d1dd; https://git.kernel.org/stable/c/0a46ef234756dca04623b7591e8ebb3440622f0b; https://git.kernel.org/stable/c/[PII_REDACTED]4bffd0a34fba070ad9367de058752
CVE: CVE-2024-40973
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mtk-vcodec: potential null pointer deference in SCP

The return value of devm_kzalloc() needs to be checked to avoid
NULL pointer deference. This is similar to CVE-2022-3113.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3a693c7e243b932faee5c1fb728efa73f0abc39b; https://git.kernel.org/stable/c/53dbe08504442dc7ba4865c09b3bbf5fe849681b; https://git.kernel.org/stable/c/eeb62bb4ca22db17f7dfe8fb8472e0442df3d92f
CVE: CVE-2024-40974
Published: 2024-07-12
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/pseries: Enforce hcall result buffer validity and size

plpar_hcall(), plpar_hcall9(), and related functions expect callers to
provide valid result buffers of certain minimum size. Currently this
is communicated only through comments in the code and the compiler has
no idea.

For example, if I write a bug like this:

  long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE
  plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);

This compiles with no diagnostics emitted, but likely results in stack
corruption at runtime when plpar_hcall9() stores results past the end
of the array. (To be clear this is a contrived example and I have not
found a real instance yet.)

To make this class of error less likely, we can use explicitly-sized
array parameters instead of pointers in the declarations for the hcall
APIs. When compiled with -Warray-bounds[1], the code above now
provokes a diagnostic like this:

error: array argument is too small;
is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]
   60 |                 plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,
      |                 ^                                   ~~~~~~

[1] Enabled for LLVM builds but not GCC for now. See commit
    0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and
    related changes.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/19c166ee42cf16d8b156a6cb4544122d9a65d3ca; https://git.kernel.org/stable/c/262e942ff5a839b9e4f3302a8987928b0c8b8a2d; https://git.kernel.org/stable/c/3ad0034910a57aa88ed9976b1431b7b8c84e0048