Page 7 of 4520 results (0.015 seconds)

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net/smc: protect link down work from execute after lgr freed link down work may be scheduled before lgr freed but execute after lgr freed, which may result in crash. So it is need to hold a reference before shedule link down work, and put the reference after work executed or canceled. The relevant crash call stack as follows: list_del corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smc_link_down_work [smc] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsem_down_write_slowpath+0x17e/0x470 smc_link_down_work+0x3c/0x60 [smc] process_one_work+0x1ac/0x350 worker_thread+0x49/0x2f0 ? rescuer_thread+0x360/0x360 kthread+0x118/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x1f/0x30 • https://git.kernel.org/stable/c/541afa10c126b6c22c2a805a559c70cc41fd156e https://git.kernel.org/stable/c/bec2f52866d511e94c1c37cd962e4382b1b1a299 https://git.kernel.org/stable/c/2627c3e8646932dfc7b9722c88c2e1ffcf7a9fb2 https://git.kernel.org/stable/c/841b1824750d3b8d1dc0a96b14db4418b952abbc https://git.kernel.org/stable/c/2b33eb8f1b3e8c2f87cfdbc8cc117f6bdfabc6ec •

CVSS: -EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: mscc: ocelot: fix incorrect IFH SRC_PORT field in ocelot_ifh_set_basic() Packets injected by the CPU should have a SRC_PORT field equal to the CPU port module index in the Analyzer block (ocelot->num_phys_ports). The blamed commit copied the ocelot_ifh_set_basic() call incorrectly from ocelot_xmit_common() in net/dsa/tag_ocelot.c. Instead of calling with "x", it calls with BIT_ULL(x), but the field is not a port mask, but rather a single port index. [ side note: this is the technical debt of code duplication :( ] The error used to be silent and doesn't appear to have other user-visible manifestations, but with new changes in the packing library, it now fails loudly as follows: ------------[ cut here ]------------ Cannot store 0x40 inside bits 46-43 - will truncate sja1105 spi2.0: xmit timed out WARNING: CPU: 1 PID: 102 at lib/packing.c:98 __pack+0x90/0x198 sja1105 spi2.0: timed out polling for tstamp CPU: 1 UID: 0 PID: 102 Comm: felix_xmit Tainted: G W N 6.13.0-rc1-00372-gf706b85d972d-dirty #2605 Call trace: __pack+0x90/0x198 (P) __pack+0x90/0x198 (L) packing+0x78/0x98 ocelot_ifh_set_basic+0x260/0x368 ocelot_port_inject_frame+0xa8/0x250 felix_port_deferred_xmit+0x14c/0x258 kthread_worker_fn+0x134/0x350 kthread+0x114/0x138 The code path pertains to the ocelot switchdev driver and to the felix secondary DSA tag protocol, ocelot-8021q. Here seen with ocelot-8021q. The messenger (packing) is not really to blame, so fix the original commit instead. • https://git.kernel.org/stable/c/06bcb9032e05ad717f9fd0a6e2fd3ae7f430fa31 https://git.kernel.org/stable/c/ff7f554bbd75d5cbf00cded81d05147c6617e876 https://git.kernel.org/stable/c/e1b9e80236c540fa85d76e2d510d1b38e1968c5d https://git.kernel.org/stable/c/be3a532167dd562ec38900c846e7ae6cc39aa2f1 https://git.kernel.org/stable/c/59c4ca8d8d7918eb6e2df91d2c254827264be309 https://git.kernel.org/stable/c/2f3c62ffe88116cd2a39cd73e01103535599970f https://git.kernel.org/stable/c/a8836eae3288c351acd3b2743d2fad2a4ee2bd56 https://git.kernel.org/stable/c/2d5df3a680ffdaf606baa10636bdb1daf •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: netdevsim: prevent bad user input in nsim_dev_health_break_write() If either a zero count or a large one is provided, kernel can crash. • https://git.kernel.org/stable/c/82c93a87bf8bc0cdb5ec2ab99da7d87715ff889f https://git.kernel.org/stable/c/d10321be26ff9e9e912697e9e8448099654ff561 https://git.kernel.org/stable/c/470c5ecbac2f19b1cdee2a6ce8d5650c3295c94b https://git.kernel.org/stable/c/8e9ef6bdf71bf25f4735e0230ce1919de8985835 https://git.kernel.org/stable/c/ee76746387f6233bdfa93d7406990f923641568f •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ionic: Fix netdev notifier unregister on failure If register_netdev() fails, then the driver leaks the netdev notifier. Fix this by calling ionic_lif_unregister() on register_netdev() failure. This will also call ionic_lif_unregister_phc() if it has already been registered. • https://git.kernel.org/stable/c/30b87ab4c0b30e0f681cb7dfaab6c642dd17e454 https://git.kernel.org/stable/c/da93a12876f8b969df7316dc93aac7e725f88252 https://git.kernel.org/stable/c/da5736f516a664a9e1ff74902663c64c423045d2 https://git.kernel.org/stable/c/ee2e931b2b46de9af7f681258e8ec8e2cd81cfc6 https://git.kernel.org/stable/c/9590d32e090ea2751e131ae5273859ca22f5ac14 •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ionic: no double destroy workqueue There are some FW error handling paths that can cause us to try to destroy the workqueue more than once, so let's be sure we're checking for that. The case where this popped up was in an AER event where the handlers got called in such a way that ionic_reset_prepare() and thus ionic_dev_teardown() got called twice in a row. The second time through the workqueue was already destroyed, and destroy_workqueue() choked on the bad wq pointer. We didn't hit this in AER handler testing before because at that time we weren't using a private workqueue. Later we replaced the use of the system workqueue with our own private workqueue but hadn't rerun the AER handler testing since then. • https://git.kernel.org/stable/c/9e25450da7006cd6f425248a5b38dad4adb3c981 https://git.kernel.org/stable/c/13355dd37e22edbcb99c599f783233188740a650 https://git.kernel.org/stable/c/746e6ae2e202b062b9deee7bd86d94937997ecd7 •