{"schema_version":"1.7.2","id":"OESA-2024-1766","modified":"2024-06-28T11:08:21Z","published":"2024-06-28T11:08:21Z","upstream":["CVE-2024-36477","CVE-2024-36883","CVE-2024-36898","CVE-2024-36902","CVE-2024-36903","CVE-2024-36905","CVE-2024-36919","CVE-2024-36928","CVE-2024-36968","CVE-2024-36974","CVE-2024-36975","CVE-2024-36977","CVE-2024-36978","CVE-2024-38538","CVE-2024-38541","CVE-2024-38549","CVE-2024-38587","CVE-2024-38596","CVE-2024-38601","CVE-2024-38605","CVE-2024-38636"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntpm_tis_spi: Account for SPI header when allocating TPM SPI xfer buffer\r\n\r\nThe TPM SPI transfer mechanism uses MAX_SPI_FRAMESIZE for computing the\nmaximum transfer length and the size of the transfer buffer. As such, it\ndoes not account for the 4 bytes of header that prepends the SPI data\nframe. This can result in out-of-bounds accesses and was confirmed with\nKASAN.\r\n\r\nIntroduce SPI_HDRSIZE to account for the header and use to allocate the\ntransfer buffer.(CVE-2024-36477)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix out-of-bounds access in ops_init\r\n\r\nnet_alloc_generic is called by net_alloc, which is called without any\nlocking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It\nis read twice, first to allocate an array, then to set s.len, which is\nlater used to limit the bounds of the array access.\r\n\r\nIt is possible that the array is allocated and another thread is\nregistering a new pernet ops, increments max_gen_ptrs, which is then used\nto set s.len with a larger than allocated length for the variable array.\r\n\r\nFix it by reading max_gen_ptrs only once in net_alloc_generic. If\nmax_gen_ptrs is later incremented, it will be caught in net_assign_generic.(CVE-2024-36883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpiolib: cdev: fix uninitialised kfifo\r\n\r\nIf a line is requested with debounce, and that results in debouncing\nin software, and the line is subsequently reconfigured to enable edge\ndetection then the allocation of the kfifo to contain edge events is\noverlooked.  This results in events being written to and read from an\nuninitialised kfifo.  Read events are returned to userspace.\r\n\r\nInitialise the kfifo in the case where the software debounce is\nalready active.(CVE-2024-36898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()\r\n\r\nsyzbot is able to trigger the following crash [1],\ncaused by unsafe ip6_dst_idev() use.\r\n\r\nIndeed ip6_dst_idev() can return NULL, and must always be checked.\r\n\r\n[1]\r\n\r\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]\n RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267\nCode: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c\nRSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700\nRDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760\nRBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd\nR10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000\nR13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00\nFS:  00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317\n  fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108\n  ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]\n  ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649\n  ip6_route_output include/net/ip6_route.h:93 [inline]\n  ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120\n  ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250\n  sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326\n  sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455\n  sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662\n  sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099\n  __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197\n  sctp_connect net/sctp/socket.c:4819 [inline]\n  sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834\n  __sys_connect_file net/socket.c:2048 [inline]\n  __sys_connect+0x2df/0x310 net/socket.c:2065\n  __do_sys_connect net/socket.c:2075 [inline]\n  __se_sys_connect net/socket.c:2072 [inline]\n  __x64_sys_connect+0x7a/0x90 net/socket.c:2072\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: Fix potential uninit-value access in __ip6_make_skb()\r\n\r\nAs it was done in commit fc1092f51567 (\u0026quot;ipv4: Fix uninit-value access in\n__ip_make_skb()\u0026quot;) for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6-\u0026gt;flowi6_flags\ninstead of testing HDRINCL on the socket to avoid a race condition which\ncauses uninit-value access.(CVE-2024-36903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets\r\n\r\nTCP_SYN_RECV state is really special, it is only used by\ncross-syn connections, mostly used by fuzzers.\r\n\r\nIn the following crash [1], syzbot managed to trigger a divide\nby zero in tcp_rcv_space_adjust()\r\n\r\nA socket makes the following state transitions,\nwithout ever calling tcp_init_transfer(),\nmeaning tcp_init_buffer_space() is also not called.\r\n\r\n         TCP_CLOSE\nconnect()\n         TCP_SYN_SENT\n         TCP_SYN_RECV\nshutdown() -\u0026gt; tcp_shutdown(sk, SEND_SHUTDOWN)\n         TCP_FIN_WAIT1\r\n\r\nTo fix this issue, change tcp_shutdown() to not\nperform a TCP_SYN_RECV -\u0026gt; TCP_FIN_WAIT1 transition,\nwhich makes no sense anyway.\r\n\r\nWhen tcp_rcv_state_process() later changes socket state\nfrom TCP_SYN_RECV to TCP_ESTABLISH, then look at\nsk-\u0026gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,\nand send a FIN packet from a sane socket state.\r\n\r\nThis means tcp_send_fin() can now be called from BH\ncontext, and must use GFP_ATOMIC allocations.\r\n\r\n[1]\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767\nCode: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 \u0026lt;48\u0026gt; f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48\nRSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246\nRAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7\nR10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30\nR13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da\nFS:  00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513\n  tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578\n  inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680\n  sock_recvmsg_nosec net/socket.c:1046 [inline]\n  sock_recvmsg+0x109/0x280 net/socket.c:1068\n  ____sys_recvmsg+0x1db/0x470 net/socket.c:2803\n  ___sys_recvmsg net/socket.c:2845 [inline]\n  do_recvmmsg+0x474/0xae0 net/socket.c:2939\n  __sys_recvmmsg net/socket.c:3018 [inline]\n  __do_sys_recvmmsg net/socket.c:3041 [inline]\n  __se_sys_recvmmsg net/socket.c:3034 [inline]\n  __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7faeb6363db9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9\nRDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005\nRBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c\nR10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload\r\n\r\nThe session resources are used by FW and driver when session is offloaded,\nonce session is uploaded these resources are not used. The lock is not\nrequired as these fields won\u0026apos;t be used any longer. The offload and upload\ncalls are sequential, hence lock is not required.\r\n\r\nThis will suppress following BUG_ON():\r\n\r\n[  449.843143] ------------[ cut here ]------------\n[  449.848302] kernel BUG at mm/vmalloc.c:2727!\n[  449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[  449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1\nRebooting.\n[  449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016\n[  449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]\n[  449.882910] RIP: 0010:vunmap+0x2e/0x30\n[  449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 \u0026lt;0f\u0026gt; 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41\n[  449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206\n[  449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005\n[  449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000\n[  449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf\n[  449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000\n[  449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0\n[  449.953701] FS:  0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000\n[  449.962732] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0\n[  449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  449.993028] Call Trace:\n[  449.995756]  __iommu_dma_free+0x96/0x100\n[  450.000139]  bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]\n[  450.006171]  bnx2fc_upload_session+0xce/0x100 [bnx2fc]\n[  450.011910]  bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]\n[  450.018136]  fc_rport_work+0x103/0x5b0 [libfc]\n[  450.023103]  process_one_work+0x1e8/0x3c0\n[  450.027581]  worker_thread+0x50/0x3b0\n[  450.031669]  ? rescuer_thread+0x370/0x370\n[  450.036143]  kthread+0x149/0x170\n[  450.039744]  ? set_kthread_struct+0x40/0x40\n[  450.044411]  ret_from_fork+0x22/0x30\n[  450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls\n[  450.048497]  libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler\n[  450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/qeth: Fix kernel panic after setting hsuid\r\n\r\nSymptom:\nWhen the hsuid attribute is set for the first time on an IQD Layer3\ndevice while the corresponding network interface is already UP,\nthe kernel will try to execute a napi function pointer that is NULL.\r\n\r\nExample:\n---------------------------------------------------------------------------\n[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP\n[ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6\nnft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de\ns_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod\n qdio ccwgroup pkey zcrypt\n[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1\n[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)\n[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)\n[ 2057.572748]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3\n[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000\n[ 2057.572754]            00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80\n[ 2057.572756]            000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8\n[ 2057.572758]            00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68\n[ 2057.572762] Krnl Code:#0000000000000000: 0000                illegal\n                         \u0026gt;0000000000000002: 0000                illegal\n                          0000000000000004: 0000                illegal\n                          0000000000000006: 0000                illegal\n                          0000000000000008: 0000                illegal\n                          000000000000000a: 0000                illegal\n                          000000000000000c: 0000                illegal\n                          000000000000000e: 0000                illegal\n[ 2057.572800] Call Trace:\n[ 2057.572801] ([\u0026lt;00000000ec639700\u0026gt;] 0xec639700)\n[ 2057.572803]  [\u0026lt;00000000913183e2\u0026gt;] net_rx_action+0x2ba/0x398\n[ 2057.572809]  [\u0026lt;0000000091515f76\u0026gt;] __do_softirq+0x11e/0x3a0\n[ 2057.572813]  [\u0026lt;0000000090ce160c\u0026gt;] do_softirq_own_stack+0x3c/0x58\n[ 2057.572817] ([\u0026lt;0000000090d2cbd6\u0026gt;] do_softirq.part.1+0x56/0x60)\n[ 2057.572822]  [\u0026lt;0000000090d2cc60\u0026gt;] __local_bh_enable_ip+0x80/0x98\n[ 2057.572825]  [\u0026lt;0000000091314706\u0026gt;] __dev_queue_xmit+0x2be/0xd70\n[ 2057.572827]  [\u0026lt;000003ff803dd6d6\u0026gt;] afiucv_hs_send+0x24e/0x300 [af_iucv]\n[ 2057.572830]  [\u0026lt;000003ff803dd88a\u0026gt;] iucv_send_ctrl+0x102/0x138 [af_iucv]\n[ 2057.572833]  [\u0026lt;000003ff803de72a\u0026gt;] iucv_sock_connect+0x37a/0x468 [af_iucv]\n[ 2057.572835]  [\u0026lt;00000000912e7e90\u0026gt;] __sys_connect+0xa0/0xd8\n[ 2057.572839]  [\u0026lt;00000000912e9580\u0026gt;] sys_socketcall+0x228/0x348\n[ 2057.572841]  [\u0026lt;0000000091514e1a\u0026gt;] system_call+0x2a6/0x2c8\n[ 2057.572843] Last Breaking-Event-Address:\n[ 2057.572844]  [\u0026lt;0000000091317e44\u0026gt;] __napi_poll+0x4c/0x1d8\n[ 2057.572846]\n[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt\n-------------------------------------------------------------------------------------------\r\n\r\nAnalysis:\nThere is one napi structure per out_q: card-\u0026gt;qdio.out_qs[i].napi\nThe napi.poll functions are set during qeth_open().\r\n\r\nSince\ncommit 1cfef80d4c2b (\u0026quot;s390/qeth: Don\u0026apos;t call dev_close/dev_open (DOWN/UP)\u0026quot;)\nqeth_set_offline()/qeth_set_online() no longer call dev_close()/\ndev_open(). So if qeth_free_qdio_queues() cleared\ncard-\u0026gt;qdio.out_qs[i].napi.poll while the network interface was UP and the\ncard was offline, they are not set again.\r\n\r\nReproduction:\nchzdev -e $devno layer2=0\nip link set dev $network_interface up\necho 0 \u0026gt; /sys/bus/ccw\n---truncated---(CVE-2024-36928)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()\r\n\r\nl2cap_le_flowctl_init() can cause both div-by-zero and an integer\noverflow since hdev-\u0026gt;le_mtu may not fall in the valid range.\r\n\r\nMove MTU from hci_dev to hci_conn to validate MTU and stop the connection\nprocess earlier if MTU is invalid.\nAlso, add a missing validation in read_buffer_size() and make it return\nan error value if the validation fails.\nNow hci_conn_add() returns ERR_PTR() as it can fail due to the both a\nkzalloc failure and invalid MTU value.\r\n\r\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G        W          6.9.0-rc5+ #20\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nWorkqueue: hci0 hci_rx_work\nRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547\nCode: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c\n89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 \u0026lt;66\u0026gt; f7 f3 89 c3 ff c3 4d 8d\nb7 88 00 00 00 4c 89 f0 48 c1 e8 03 42\nRSP: 0018:ffff88810bc0f858 EFLAGS: 00010246\nRAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000\nRDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f\nRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa\nR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084\nR13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000\nFS:  0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]\n l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]\n l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]\n l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809\n l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506\n hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]\n hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335\n worker_thread+0x926/0xe70 kernel/workqueue.c:3416\n kthread+0x2e3/0x380 kernel/kthread.c:388\n ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---(CVE-2024-36968)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP\r\n\r\nIf one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided,\ntaprio_parse_mqprio_opt() must validate it, or userspace\ncan inject arbitrary data to the kernel, the second time\ntaprio_change() is called.\r\n\r\nFirst call (with valid attributes) sets dev-\u0026gt;num_tc\nto a non zero value.\r\n\r\nSecond call (with arbitrary mqprio attributes)\nreturns early from taprio_parse_mqprio_opt()\nand bad things can happen.(CVE-2024-36974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKEYS: trusted: Do not use WARN when encode fails\r\n\r\nWhen asn1_encode_sequence() fails, WARN is not the correct solution.\r\n\r\n1. asn1_encode_sequence() is not an internal function (located\n   in lib/asn1_encode.c).\n2. Location is known, which makes the stack trace useless.\n3. Results a crash if panic_on_warn is set.\r\n\r\nIt is also noteworthy that the use of WARN is undocumented, and it\nshould be avoided unless there is a carefully considered rationale to\nuse it.\r\n\r\nReplace WARN with pr_err, and print the return value instead, which is\nonly useful piece of information.(CVE-2024-36975)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: Wait unconditionally after issuing EndXfer command\r\n\r\nCurrently all controller IP/revisions except DWC3_usb3 \u0026gt;= 310a\nwait 1ms unconditionally for ENDXFER completion when IOC is not\nset. This is because DWC_usb3 controller revisions \u0026gt;= 3.10a\nsupports GUCTL2[14: Rst_actbitlater] bit which allows polling\nCMDACT bit to know whether ENDXFER command is completed.\r\n\r\nConsider a case where an IN request was queued, and parallelly\nsoft_disconnect was called (due to ffs_epfile_release). This\neventually calls stop_active_transfer with IOC cleared, hence\nsend_gadget_ep_cmd() skips waiting for CMDACT cleared during\nEndXfer. For DWC3 controllers with revisions \u0026gt;= 310a, we don\u0026apos;t\nforcefully wait for 1ms either, and we proceed by unmapping the\nrequests. If ENDXFER didn\u0026apos;t complete by this time, it leads to\nSMMU faults since the controller would still be accessing those\nrequests.\r\n\r\nFix this by ensuring ENDXFER completion by adding 1ms delay in\n__dwc3_stop_active_transfer() unconditionally.(CVE-2024-36977)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: sched: sch_multiq: fix possible OOB write in multiq_tune()\r\n\r\nq-\u0026gt;bands will be assigned to qopt-\u0026gt;bands to execute subsequent code logic\nafter kmalloc. So the old q-\u0026gt;bands should not be used in kmalloc.\nOtherwise, an out-of-bounds write will occur.(CVE-2024-36978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: bridge: xmit: make sure we have at least eth header len bytes\r\n\r\nsyzbot triggered an uninit value[1] error in bridge device\u0026apos;s xmit path\nby sending a short (less than ETH_HLEN bytes) skb. To fix it check if\nwe can actually pull that amount instead of assuming.\r\n\r\nTested with dropwatch:\n drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)\n origin: software\n timestamp: Mon May 13 11:31:53 2024 778214037 nsec\n protocol: 0x88a8\n length: 2\n original length: 2\n drop reason: PKT_TOO_SMALL\r\n\r\n[1]\nBUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547\n __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n __bpf_tx_skb net/core/filter.c:2136 [inline]\n __bpf_redirect_common net/core/filter.c:2180 [inline]\n __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187\n ____bpf_clone_redirect net/core/filter.c:2460 [inline]\n bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432\n ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997\n __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238\n bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]\n __bpf_prog_run include/linux/filter.h:657 [inline]\n bpf_prog_run include/linux/filter.h:664 [inline]\n bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425\n bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058\n bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269\n __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678\n __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]\n __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765\n x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-38538)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: add buffer overflow check in of_modalias()\r\n\r\nIn of_modalias(), if the buffer happens to be too small even for the 1st\nsnprintf() call, the len parameter will become negative and str parameter\n(if not NULL initially) will point beyond the buffer\u0026apos;s end. Add the buffer\noverflow check after the 1st snprintf() call and fix such check after the\nstrlen() call (accounting for the terminating NUL char).(CVE-2024-38541)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/mediatek: Add 0 size check to mtk_drm_gem_obj\r\n\r\nAdd a check to mtk_drm_gem_init if we attempt to allocate a GEM object\nof 0 bytes. Currently, no such check exists and the kernel will panic if\na userspace application attempts to allocate a 0x0 GBM buffer.\r\n\r\nTested by attempting to allocate a 0x0 GBM buffer on an MT8188 and\nverifying that we now return EINVAL.(CVE-2024-38549)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspeakup: Fix sizeof() vs ARRAY_SIZE() bug\r\n\r\nThe \u0026quot;buf\u0026quot; pointer is an array of u16 values.  This code should be\nusing ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512),\notherwise it can the still got out of bounds.(CVE-2024-38587)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\naf_unix: Fix data races in unix_release_sock/unix_stream_sendmsg\r\n\r\nA data-race condition has been identified in af_unix. In one data path,\nthe write function unix_release_sock() atomically writes to\nsk-\u0026gt;sk_shutdown using WRITE_ONCE. However, on the reader side,\nunix_stream_sendmsg() does not read it atomically. Consequently, this\nissue is causing the following KCSAN splat to occur:\r\n\r\n\tBUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg\r\n\r\n\twrite (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:\n\tunix_release_sock (net/unix/af_unix.c:640)\n\tunix_release (net/unix/af_unix.c:1050)\n\tsock_close (net/socket.c:659 net/socket.c:1421)\n\t__fput (fs/file_table.c:422)\n\t__fput_sync (fs/file_table.c:508)\n\t__se_sys_close (fs/open.c:1559 fs/open.c:1541)\n\t__x64_sys_close (fs/open.c:1541)\n\tx64_sys_call (arch/x86/entry/syscall_64.c:33)\n\tdo_syscall_64 (arch/x86/entry/common.c:?)\n\tentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\n\tread to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:\n\tunix_stream_sendmsg (net/unix/af_unix.c:2273)\n\t__sock_sendmsg (net/socket.c:730 net/socket.c:745)\n\t____sys_sendmsg (net/socket.c:2584)\n\t__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)\n\t__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)\n\tx64_sys_call (arch/x86/entry/syscall_64.c:33)\n\tdo_syscall_64 (arch/x86/entry/common.c:?)\n\tentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\n\tvalue changed: 0x01 -\u0026gt; 0x03\r\n\r\nThe line numbers are related to commit dd5a440a31fa (\u0026quot;Linux 6.9-rc7\u0026quot;).\r\n\r\nCommit e1d09c2c2f57 (\u0026quot;af_unix: Fix data races around sk-\u0026gt;sk_shutdown.\u0026quot;)\naddressed a comparable issue in the past regarding sk-\u0026gt;sk_shutdown.\nHowever, it overlooked resolving this particular data path.\nThis patch only offending unix_stream_sendmsg() function, since the\nother reads seem to be protected by unix_state_lock() as discussed in(CVE-2024-38596)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nring-buffer: Fix a race between readers and resize checks\r\n\r\nThe reader code in rb_get_reader_page() swaps a new reader page into the\nring buffer by doing cmpxchg on old-\u0026gt;list.prev-\u0026gt;next to point it to the\nnew page. Following that, if the operation is successful,\nold-\u0026gt;list.next-\u0026gt;prev gets updated too. This means the underlying\ndoubly-linked list is temporarily inconsistent, page-\u0026gt;prev-\u0026gt;next or\npage-\u0026gt;next-\u0026gt;prev might not be equal back to page for some page in the\nring buffer.\r\n\r\nThe resize operation in ring_buffer_resize() can be invoked in parallel.\nIt calls rb_check_pages() which can detect the described inconsistency\nand stop further tracing:\r\n\r\n[  190.271762] ------------[ cut here ]------------\n[  190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0\n[  190.271789] Modules linked in: [...]\n[  190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1\n[  190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G            E      6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f\n[  190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014\n[  190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0\n[  190.272023] Code: [...]\n[  190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206\n[  190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80\n[  190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700\n[  190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000\n[  190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720\n[  190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000\n[  190.272053] FS:  00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000\n[  190.272057] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0\n[  190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  190.272077] Call Trace:\n[  190.272098]  \u0026lt;TASK\u0026gt;\n[  190.272189]  ring_buffer_resize+0x2ab/0x460\n[  190.272199]  __tracing_resize_ring_buffer.part.0+0x23/0xa0\n[  190.272206]  tracing_resize_ring_buffer+0x65/0x90\n[  190.272216]  tracing_entries_write+0x74/0xc0\n[  190.272225]  vfs_write+0xf5/0x420\n[  190.272248]  ksys_write+0x67/0xe0\n[  190.272256]  do_syscall_64+0x82/0x170\n[  190.272363]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  190.272373] RIP: 0033:0x7f1bd657d263\n[  190.272381] Code: [...]\n[  190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[  190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263\n[  190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001\n[  190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000\n[  190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500\n[  190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002\n[  190.272412]  \u0026lt;/TASK\u0026gt;\n[  190.272414] ---[ end trace 0000000000000000 ]---\r\n\r\nNote that ring_buffer_resize() calls rb_check_pages() only if the parent\ntrace_buffer has recording disabled. Recent commit d78ab792705c\n(\u0026quot;tracing: Stop current tracer when resizing buffer\u0026quot;) causes that it is\nnow always the case which makes it more likely to experience this issue.\r\n\r\nThe window to hit this race is nonetheless very small. To help\nreproducing it, one can add a delay loop in rb_get_reader_page():\r\n\r\n ret = rb_head_page_replace(reader, cpu_buffer-\u0026gt;reader_page);\n if (!ret)\n \tgoto spin;\n for (unsigned i = 0; i \u0026lt; 1U \u0026lt;\u0026lt; 26; i++)  /* inserted delay loop */\n \t__asm__ __volatile__ (\u0026quot;\u0026quot; : : : \u0026quot;memory\u0026quot;);\n rb_list_head(reader-\u0026gt;list.next)-\u0026gt;prev = \u0026amp;cpu_buffer-\u0026gt;reader_page-\u0026gt;list;\r\n\r\n.. \n---truncated---(CVE-2024-38601)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: core: Fix NULL module pointer assignment at card init\r\n\r\nThe commit 81033c6b584b (\u0026quot;ALSA: core: Warn on empty module\u0026quot;)\nintroduced a WARN_ON() for a NULL module pointer passed at snd_card\nobject creation, and it also wraps the code around it with \u0026apos;#ifdef\nMODULE\u0026apos;.  This works in most cases, but the devils are always in\ndetails.  \u0026quot;MODULE\u0026quot; is defined when the target code (i.e. the sound\ncore) is built as a module; but this doesn\u0026apos;t mean that the caller is\nalso built-in or not.  Namely, when only the sound core is built-in\n(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),\nthe passed module pointer is ignored even if it\u0026apos;s non-NULL, and\ncard-\u0026gt;module remains as NULL.  This would result in the missing module\nreference up/down at the device open/close, leading to a race with the\ncode execution after the module removal.\r\n\r\nFor addressing the bug, move the assignment of card-\u0026gt;module again out\nof ifdef.  The WARN_ON() is still wrapped with ifdef because the\nmodule can be really NULL when all sound drivers are built-in.\r\n\r\nNote that we keep \u0026apos;ifdef MODULE\u0026apos; for WARN_ON(), otherwise it would\nlead to a false-positive NULL module check.  Admittedly it won\u0026apos;t catch\nperfectly, i.e. no check is performed when CONFIG_SND=y.  But, it\u0026apos;s no\nreal problem as it\u0026apos;s only for debugging, and the condition is pretty\nrare.(CVE-2024-38605)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: multidev: fix to recognize valid zero block address\r\n\r\nAs reported by Yi Zhang in mailing list [1], kernel warning was catched\nduring zbd/010 test as below:\r\n\r\n./check zbd/010\nzbd/010 (test gap zone support with F2FS)                    [failed]\n    runtime    ...  3.752s\n    something found in dmesg:\n    [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13\n    [ 4378.192349] null_blk: module loaded\n    [ 4378.209860] null_blk: disk nullb0 created\n    [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim\npoll_queues to 0. poll_q/nr_hw = (0/1)\n    [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520]\n                     dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0\n    [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux\nscsi_debug       0191 PQ: 0 ANSI: 7\n    [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred\n    [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20\n    [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device\n    ...\n    (See \u0026apos;/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg\u0026apos;\r\n\r\nWARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51\nCPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1\nRIP: 0010:iomap_iter+0x32b/0x350\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __iomap_dio_rw+0x1df/0x830\n f2fs_file_read_iter+0x156/0x3d0 [f2fs]\n aio_read+0x138/0x210\n io_submit_one+0x188/0x8c0\n __x64_sys_io_submit+0x8c/0x1a0\n do_syscall_64+0x86/0x170\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nShinichiro Kawasaki helps to analyse this issue and proposes a potential\nfixing patch in [2].\r\n\r\nQuoted from reply of Shinichiro Kawasaki:\r\n\r\n\u0026quot;I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a\nlook in the commit, but it looks fine to me. So I thought the cause is not\nin the commit diff.\r\n\r\nI found the WARN is printed when the f2fs is set up with multiple devices,\nand read requests are mapped to the very first block of the second device in the\ndirect read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached()\nmodify map-\u0026gt;m_pblk as the physical block address from each block device. It\nbecomes zero when it is mapped to the first block of the device. However,\nf2fs_iomap_begin() assumes that map-\u0026gt;m_pblk is the physical block address of the\nwhole f2fs, across the all block devices. It compares map-\u0026gt;m_pblk against\nNULL_ADDR == 0, then go into the unexpected branch and sets the invalid\niomap-\u0026gt;length. The WARN catches the invalid iomap-\u0026gt;length.\r\n\r\nThis WARN is printed even for non-zoned block devices, by following steps.\r\n\r\n - Create two (non-zoned) null_blk devices memory backed with 128MB size each:\n   nullb0 and nullb1.\n # mkfs.f2fs /dev/nullb0 -c /dev/nullb1\n # mount -t f2fs /dev/nullb0 \u0026quot;${mount_dir}\u0026quot;\n # dd if=/dev/zero of=\u0026quot;${mount_dir}/test.dat\u0026quot; bs=1M count=192\n # dd if=\u0026quot;${mount_dir}/test.dat\u0026quot; of=/dev/null bs=1M count=192 iflag=direct\r\n\r\n...\u0026quot;\r\n\r\nSo, the root cause of this issue is: when multi-devices feature is on,\nf2fs_map_blocks() may return zero blkaddr in non-primary device, which is\na verified valid block address, however, f2fs_iomap_begin() treats it as\nan invalid block address, and then it triggers the warning in iomap\nframework code.\r\n\r\nFinally, as discussed, we decide to use a more simple and direct way that\nchecking (map.m_flags \u0026amp; F2FS_MAP_MAPPED) condition instead of\n(map.m_pblk != NULL_ADDR) to fix this issue.\r\n\r\nThanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this\nissue.\r\n\r\n[1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/\n[2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/(CVE-2024-38636)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-31.0.0.39.oe2403"}]}],"ecosystem_specific":{"aarch64":["kernel-6.6.0-31.0.0.39.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-31.0.0.39.oe2403.aarch64.rpm","kernel-tools-6.6.0-31.0.0.39.oe2403.aarch64.rpm","kernel-devel-6.6.0-31.0.0.39.oe2403.aarch64.rpm","python3-perf-6.6.0-31.0.0.39.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm","perf-6.6.0-31.0.0.39.oe2403.aarch64.rpm","bpftool-6.6.0-31.0.0.39.oe2403.aarch64.rpm","kernel-headers-6.6.0-31.0.0.39.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm","kernel-source-6.6.0-31.0.0.39.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-31.0.0.39.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-31.0.0.39.oe2403.src.rpm"],"x86_64":["bpftool-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm","kernel-headers-6.6.0-31.0.0.39.oe2403.x86_64.rpm","python3-perf-6.6.0-31.0.0.39.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-31.0.0.39.oe2403.x86_64.rpm","perf-6.6.0-31.0.0.39.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm","kernel-6.6.0-31.0.0.39.oe2403.x86_64.rpm","kernel-source-6.6.0-31.0.0.39.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm","kernel-tools-6.6.0-31.0.0.39.oe2403.x86_64.rpm","kernel-devel-6.6.0-31.0.0.39.oe2403.x86_64.rpm","bpftool-6.6.0-31.0.0.39.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-31.0.0.39.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1766"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36477"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36883"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36898"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36902"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36903"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36905"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36919"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36928"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36968"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36974"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36975"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36977"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36978"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38538"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38541"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38549"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38587"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38596"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38601"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38605"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38636"}],"database_specific":{"severity":"High"}}