{"schema_version":"1.7.2","id":"OESA-2024-1898","modified":"2024-07-26T11:08:37Z","published":"2024-07-26T11:08:37Z","upstream":["CVE-2022-48814","CVE-2024-36939","CVE-2024-40904","CVE-2024-40905"],"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\nnet: dsa: seville: register the mdiobus under devres\r\n\r\nAs explained in commits:\n74b6d7d13307 (\u0026quot;net: dsa: realtek: register the MDIO bus under devres\u0026quot;)\n5135e96a3dd2 (\u0026quot;net: dsa: don\u0026apos;t allocate the slave_mii_bus using devres\u0026quot;)\r\n\r\nmdiobus_free() will panic when called from devm_mdiobus_free() \u0026lt;-\ndevres_release_all() \u0026lt;- __device_release_driver(), and that mdiobus was\nnot previously unregistered.\r\n\r\nThe Seville VSC9959 switch is a platform device, so the initial set of\nconstraints that I thought would cause this (I2C or SPI buses which call\n-\u0026gt;remove on -\u0026gt;shutdown) do not apply. But there is one more which\napplies here.\r\n\r\nIf the DSA master itself is on a bus that calls -\u0026gt;remove from -\u0026gt;shutdown\n(like dpaa2-eth, which is on the fsl-mc bus), there is a device link\nbetween the switch and the DSA master, and device_links_unbind_consumers()\nwill unbind the seville switch driver on shutdown.\r\n\r\nSo the same treatment must be applied to all DSA switch drivers, which\nis: either use devres for both the mdiobus allocation and registration,\nor don\u0026apos;t use devres at all.\r\n\r\nThe seville driver has a code structure that could accommodate both the\nmdiobus_unregister and mdiobus_free calls, but it has an external\ndependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls\ndevm_mdiobus_alloc_size() on its behalf. So rather than restructuring\nthat, and exporting yet one more symbol mscc_miim_teardown(), let\u0026apos;s work\nwith devres and replace of_mdiobus_register with the devres variant.\nWhen we use all-devres, we can ensure that devres doesn\u0026apos;t free a\nstill-registered bus (it either runs both callbacks, or none).(CVE-2022-48814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfs: Handle error of rpc_proc_register() in nfs_net_init().\r\n\r\nsyzkaller reported a warning [0] triggered while destroying immature\nnetns.\r\n\r\nrpc_proc_register() was called in init_nfs_fs(), but its error\nhas been ignored since at least the initial commit 1da177e4c3f4\n(\u0026quot;Linux-2.6.12-rc2\u0026quot;).\r\n\r\nRecently, commit d47151b79e32 (\u0026quot;nfs: expose /proc/net/sunrpc/nfs\nin net namespaces\u0026quot;) converted the procfs to per-netns and made\nthe problem more visible.\r\n\r\nEven when rpc_proc_register() fails, nfs_net_init() could succeed,\nand thus nfs_net_exit() will be called while destroying the netns.\r\n\r\nThen, remove_proc_entry() will be called for non-existing proc\ndirectory and trigger the warning below.\r\n\r\nLet\u0026apos;s handle the error of rpc_proc_register() properly in nfs_net_init().\r\n\r\n[0]:\nname \u0026apos;nfs\u0026apos;\nWARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711\nModules linked in:\nCPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711\nCode: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff \u0026lt;0f\u0026gt; 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb\nRSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c\nRDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc\nR13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8\nFS:  00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310\n nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438\n ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170\n setup_net+0x46c/0x660 net/core/net_namespace.c:372\n copy_net_ns+0x244/0x590 net/core/net_namespace.c:505\n create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110\n unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228\n ksys_unshare+0x342/0x760 kernel/fork.c:3322\n __do_sys_unshare kernel/fork.c:3393 [inline]\n __se_sys_unshare kernel/fork.c:3391 [inline]\n __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\nRIP: 0033:0x7f30d0febe5d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48\nRSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110\nRAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600\nRBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002\nR13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000\n \u0026lt;/TASK\u0026gt;(CVE-2024-36939)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages\r\n\r\nThe syzbot fuzzer found that the interrupt-URB completion callback in\nthe cdc-wdm driver was taking too long, and the driver\u0026apos;s immediate\nresubmission of interrupt URBs with -EPROTO status combined with the\ndummy-hcd emulation to cause a CPU lockup:\r\n\r\ncdc_wdm 1-1:1.0: nonzero urb status received: -71\ncdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes\nwatchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]\nCPU#0 Utilization every 4s during lockup:\n\t#1:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#2:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#3:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#4:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#5:  98% system,\t  1% softirq,\t  3% hardirq,\t  0% idle\nModules linked in:\nirq event stamp: 73096\nhardirqs last  enabled at (73095): [\u0026lt;ffff80008037bc00\u0026gt;] console_emit_next_record kernel/printk/printk.c:2935 [inline]\nhardirqs last  enabled at (73095): [\u0026lt;ffff80008037bc00\u0026gt;] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994\nhardirqs last disabled at (73096): [\u0026lt;ffff80008af10b00\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\nhardirqs last disabled at (73096): [\u0026lt;ffff80008af10b00\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\nsoftirqs last  enabled at (73048): [\u0026lt;ffff8000801ea530\u0026gt;] softirq_handle_end kernel/softirq.c:400 [inline]\nsoftirqs last  enabled at (73048): [\u0026lt;ffff8000801ea530\u0026gt;] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582\nsoftirqs last disabled at (73043): [\u0026lt;ffff800080020de8\u0026gt;] __do_softirq+0x14/0x20 kernel/softirq.c:588\nCPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G        W          6.10.0-rc2-syzkaller-g8867bbd4a056 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\r\n\r\nTesting showed that the problem did not occur if the two error\nmessages -- the first two lines above -- were removed; apparently adding\nmaterial to the kernel log takes a surprisingly large amount of time.\r\n\r\nIn any case, the best approach for preventing these lockups and to\navoid spamming the log with thousands of error messages per second is\nto ratelimit the two dev_err() calls.  Therefore we replace them with\ndev_err_ratelimited().(CVE-2024-40904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fix possible race in __fib6_drop_pcpu_from()\r\n\r\nsyzbot found a race in __fib6_drop_pcpu_from() [1]\r\n\r\nIf compiler reads more than once (*ppcpu_rt),\nsecond read could read NULL, if another cpu clears\nthe value in rt6_get_pcpu_route().\r\n\r\nAdd a READ_ONCE() to prevent this race.\r\n\r\nAlso add rcu_read_lock()/rcu_read_unlock() because\nwe rely on RCU protection while dereferencing pcpu_rt.\r\n\r\n[1]\r\n\r\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]\nCPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nWorkqueue: netns cleanup_net\n RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984\nCode: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 \u0026lt;80\u0026gt; 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48\nRSP: 0018:ffffc900040df070 EFLAGS: 00010206\nRAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16\nRDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091\nRBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007\nR10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8\nR13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001\nFS:  0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]\n  fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]\n  fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038\n  fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]\n  fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043\n  fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205\n  fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127\n  fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175\n  fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255\n  __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271\n  rt6_sync_down_dev net/ipv6/route.c:4906 [inline]\n  rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911\n  addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855\n  addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778\n  notifier_call_chain+0xb9/0x410 kernel/notifier.c:93\n  call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992\n  call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]\n  call_netdevice_notifiers net/core/dev.c:2044 [inline]\n  dev_close_many+0x333/0x6a0 net/core/dev.c:1585\n  unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193\n  unregister_netdevice_many net/core/dev.c:11276 [inline]\n  default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759\n  ops_exit_list+0x128/0x180 net/core/net_namespace.c:178\n  cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640\n  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n  process_scheduled_works kernel/workqueue.c:3312 [inline]\n  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393\n  kthread+0x2c1/0x3a0 kernel/kthread.c:389\n  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40905)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-220.0.0.119.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","kernel-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","perf-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-220.0.0.119.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","kernel-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","perf-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1898"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48814"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36939"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40904"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40905"}],"database_specific":{"severity":"Medium"}}